Next week I am presenting at two conferences: the 8th edition of 4developers (Warsaw) and the 7th annual ACE! conference (Kraków).
Together with Mariusz Sieraczkiewicz we will talk on “How To Transform Good Teams Into Awesome Ones”. We will share our experience from Agile transformations we worked on recently, including success and failure stories. Join us to learn the model we use and the steps we make while working with the teams.
See you in Warsaw or Kraków.
-Paweł
PS I will publish the slides after the conferences.
There’s no point in driving faster in the wrong direction.
That’s why staying focused on what really matters during the whole the software development process is crucial. Which means killing features that no one is going to use, shortening discussions and brining them back on track, and helping teams with difficult decisions (“Should we refactor this piece?”, “Should we allow deleting users?”, “What to work on next?” ) – I must admit I really enjoy this process 🙂
I gave a talk on this topic during the last AgileByExample 2014 conference. Here you’ll find the video:
I was recently asked “What is more in Kanban than a Taskboard and WIP limits”? Actually, there is a couple of tools that may help your Team become even more effective:
Discover Your Real Developement Process
Your Kanban board doesn’t have to be as simple as this:
It may look like that:
It all starts with a process of Value Stream Mapping, which later helps you craft a Kanban board corresponding to your process. Discovering a real development process is an insightful exercise itself – it helps the Team realise it’s more than “Pick a task, code and hand over to QA” 🙂
Measure, Chart and Improve Your Flow Efficiency
Cumulative Flow Diagram helps you look at your flow from the brid’s-eye view. As you can see here it’s a single chart that brings quite a lot of information:
That’s why when it comes to measuring and analysing average Lead and Cycle Times I prefer to look at the Control Chart that graphs these numbers for each task, like this one:
It might be interesting to analyse which tasks (and why) took significantly longer time to complete than usual.
Flow Efficiency
Another interesting measure in Kanban systems is Flow Efficiency, which is basically:
Let’s say you start working on a feature on Tuesday morning and finish it a week later. Usually, what happens meanwhile during this week is a number of activities not adding value to this feature like:
waiting – e.g. waiting for graphics design, translation or QA
multitasking – working on other items.
If the actual time spent on this particular feature by the whole team is 2 days, then the flow efficiency for this feature is 2 days (work time) / 7 days (time passed) = 28.5%.
Other Tools and Measures
These are just few examples of tools and measures related to Kanban. I haven’t mentioned Classes of Service that help you handle urgent and fixed date issues as well as Cycle Time Distribution analysis that helps you define Kanban Service Level Agreement.
What do you find useful in Kanban beyond a simple Taskboard and WIP Limits?
That made the decision to leave an extremely hard one, but I feel it’s now time for me to look for new challenges. I have decided to leave SoftwareMill for two main reasons:
1) More face-to-face interactions
Over the last years my focus has moved from programming to organisation and leading and coaching people. In short – more talking to people, less talking to computers 🙂 I really enjoy it, but it’s much harder to do remotely, which is why I want to go outside my home office.
I’ve been really enjoying working remotely for a long time. It has a number of benefits and I’d love to keep them. But since I’ve discovered how much joy face to face conversations bring to my life I want to have more of them.
2) New challenges for my personal development
SoftwareMill is doing great. There are, of course, things to improve here and there, but staying there would be staying in my comfort zone.
To say I’ve learned a lot at SoftwareMill is an understatement. I’ve learned something from everyone who I worked with. I’d like to say a huge thank you for all the time we spent together, all the conversations and ideas we had. You guys are AWESOME. I am keeping my fingers crossed for your efforts in making SoftwareMill the best place to work for IT workers.
What’s next?
I am taking a short break for a while, but I am open to proposals for collaboration – short or long-term.
My passion is helping teams and individuals to discover and focus on what really matters for them. I enjoy working with teams and on the business side of IT. And in all of this, I aim to make myself dispensable by encouraging self-organisation.
I have experience and a lot of passion to work in two areas of software development:
1) Building effective, self-organising, motivated teams
either as an Agile coach, trainer, facilitator
or as a servant leader a.k.a. Scrum Master
2) Bridging the gap between business and IT (and users)
as a Product Owner, Product Manager, User Experience specialist or all of them at once 🙂
So… if you think we could do something awesome together or just want to talk, ping me via e-mail, Skype (pawel.wrzeszcz.work), LinkedIn or Twitter.
“Distributed agile is hard” is what I often hear. And yes, after working remotely in various distributed teams for 8 years, I agree. But I am going to argue that this is a good thing.
Basically I believe that working in a distributed environment is like using Scrum – it does not solve your problems, but makes them more visible. I like to call this a “visibility shift”.
With the challenges being more visible, a distributed team can actually make it easier to adapt an agile approach to software development. Especially if it is a team where everyone works remotely (see “Remote Worker, Distributed Team”).
Value vs. presence
Working remotely makes it harder to verify whether someone is at work all the time or not. You cannot look around you and see other people sitting in front of their computers or having discussions.
And this is good. Because without this notion of presence, something else becomes more visible: the actual value delivered. Because at the end of the day what counts is not the fact that we have been to work, but the new feature or a fixed bug.
(Just to be clear: I am not saying that value delivered is not visible in the co-located environment. But in the distributed setup it is one of the very few visible signs that someone was at work. Which is great because this is what agile is all about – focusing on value.)
Communication challenges
If your team suffers from poor communication or endless meetings, working remotely will make this even more conspicuous.
It is really hard to stay awake during a long teleconference meeting. And this is good. Because it shows how useless meetings are in general. And by working remotely you will have less of them, in favor of more asynchronous communication.
Trust issues
Another thing that becomes painfully visible in the distributed setup is lack of trust.
I heard this statement from a manager on why distributed teams are hard for him: “Sometimes I have to go in person to make sure they are doing what they are supposed to”. Others are worried about their employees browsing Facebook instead of working. These are all signs that the level of trust in the team is low. And yeah… such a team would have a really hard time working in a distributed model, because the trust issue would be even more visible.
All in all
So yes, distributed teams do face challenges. But they face them because things that matter, like value delivered, communication and trust issues, are more visible to them. Which is good, because making an issue visible is the first step for improvement.
Agile Pricing – Consider models like Pay Per Feature, cause neither Fixed Price nor Time&Materials are good billing approaches (e.g. T&M does not encourage productivity).
Ideally, a Product Backlog should give the whole team a clear roadmap on work to be done.
I remember times when I actually believed this is really possible, even with a huge Backlog, but in practice in every project I worked on I struggled with keeping the Backlog up-to-date, prioritised and consistent.
Then, thanks to Roman Pichler (see Top Ten Product Backlog Tips for example) I understood that the Product Backlog requires a lot of care (well, the same way like codebase does). This includes:
Finding right wording for user stories
Writing acceptance criteria for stories
Managing stories on various level of detail, decomposing them when necessary
Removing(!) no longer valid entries from the list
Rewriting other ones
Getting stories estimated
Prioritising
and that is probably not the end of the list.
All of this done regularly!
Woow, that is a lot of work!
Reality
In practice, most of Product Owners or people responsible for Product Backlog (including myself) do not perform most of these tasks regulary, because the only really important horizons (at least in agile/lean approach) are:
This iteration/week
Upcoming release or other important date, usually within a couple of weeks from now
This means that what actually matters is on the top of the Backlog. All other stories are… well… you can either say “less important at the moment” or, I believe more correctly, “waste”.
Hovewer, over and over again I observe the following scenario:
Customer: Hey, could we have feature X in our product?
Development Team: Well… it all depends on your priorities.
Customer: Yeah, this X is really important.
Development Team: OK, in our Backlog next things to work on are Y and Z. Should we do X before?
Customer: Ah, no! Y and Z are crucial too. Hm… Maybe we could implement X immediately after Y and Z?
Development Team: Yeah, sounds like a plan. Although we will still have several important things to do after Z for the upcoming release, so we will have to see how X fits.
(silence…)
Development Team: OK, let’s put X to the Backlog and we will see.
And you know what? Quite often this X stays in the Backlog forever.
This is what I call saying “Maybe”, instead of “No”. Backlog is a safe option to close such a conversation, but unfortunatelly later on no one dares to remove anything from there, so lower part of Product Backlog becomes Idea Trash.
Possible solution
Here is what I suggest:
Keep very small, focused “Backlog” (better name “This week” or “This release”)
Put a hard limit on number stories in it. In other words, limit WIP, where story in the backlog is also considered as “in progress”
Anytime you are tempted to break the limit, remove less important stories from the Backlog
Most importantly: Have a clear working agreement that removing an item from the Backlog does not mean rejecting to do it at all. You can add such a story later when it becomes important enough.
I am using such an approach on my Personal Kanban board and I would love to give it a try in a project. Actually, this post is triggered by our hassles with managing Backlog in Codebrag and by writing my thoughts down I hope to convince my teammates to give it a try 😉 [update: We have tried it in Codebrag and it works very well]
The idea behind this is making an issue of “There is always more to be done than our capacity” more (frequently) visible. I believe that having a clear backlog helps having clear mind and making better decisions.
The argument against this approach I hear mostly is that something important or innovative might be forgotten if not written down. I disagree. If a user story really “loves” me, it will come back. Otherwise it is not worth my effort.
Altitude sickness has taught me two important insights about speed and trends, which can be applied to software development projects (and probably many other areas as well).
Photo: Krystyna Kupiszewska
Altitude sickness
After trekking above approximately 3,000 meters one has to take care not to climb too fast. The general rule is not to ascend more than 300 meters daily to acclimatise.
If your organism does not adapt to the height you reached, several symptoms appear (headache, fatigue, stomach illness, dizziness, and sleep disturbance).
This once happened to me in Nepal. The symptoms usually disappear within couple of hours. However, in some cases they may be getting worse, especially if you climbed significantly more than 300 meters within a day.
Altitude sicknes is quite a simple illness. If a patient is feeling worse and worse the end is always the same – death 😦 The only reliable treatment is to descend.
Speed limit
The first general thing I have learnt from altitude sicknes is existence of hard limit on velocity. Attempting to get above this limit is asking for trouble.
This applies to projects and speed of development as well. I like to keep that in mind when planning software development releases. Usually there is hardly anything we can to quickly achieve higher output (I am not talking about long-term improvements here) and the only reasonable option is cutting down on requirements.
Trends
Moreover, the way altitude sickness develops and comes away shows that it is all about the trends.
For instance, a percentage of code coverage in your project is relevant, but it is more important whether it is increasing or falling. The same applies to more general matters like quality, moods, financial situation and so on.
If we are on the wrong side of the trend, doing nothing and just waiting for better time to come will not help, exactly like in the case of sickness getting worse and worse.
All in all, I find those lessons on velocity limit and trends very useful – much often than in the high mountains.
Being a leader may sometimes feel like being an ambitious guy trying to sell the idea of getting up after the break and continuing hiking uphill to the group of exhausted backpackers.
How to make them stand up and go?
Stand up first
There is no other way. Just talking about any idea you want to sell to others will not work. You have to give an example, be the first one.
A mountain guide willing his group to stand up, stands up first, with a backpack on his shoulders, ready to go.
Photo courtesy of Krystyna Kupiszewska. On the photo: Jakub Organ
Make room
OK, so we have got most of people standing and almost ready (adjusting their backpacks, talking to each other, drinking water and so on).
Now, a non-obvious trick to make the “process” of starting smooth is to make few steps forward, then call and wait for them to move.
This is important because:
if you just start walking you may end up walking alone and
otherwise, if you just stand and wait right next the whole group you are actually blocking the way you want them to go.
Introducing an organizational change
From my experience introducing a change in the team or an organization usually requires following similar scenario. If you want others to adopt a practice, after showing them an example, you need to make some room for them to start.
Understanding this is important if you want people to self-organize, or even just take over some responsibilities.
A very simple example might be introducing a habit of documenting important things on a wiki. Or keeping an eye on continuous integration system. To make this ultimately happen you need to stop doing all of ityourself (not to walk alone) and stop reminding about this every time. Otherwise you block room for progress.
-Paweł
PS This post and a previous one are part of “What a ScrumMaster Can Learn From a Mountain Guide” – something that may become a short series.
See you in Warsaw or Kraków.
pawel.wrzesz.cz 