Agile Australia 2014 kicked off with a bang, with Jim Benson – author and expert on Kanban – challenging how we work in IT and on projects, particularly in the Agile world. Today I’d like to share with you what I learnt from Jim’s keynote presentation.
As a side note, this blog will form one of three micro-blogs which I’ll be writing based on the presentations that I found really valuable at Agile Australia.
One of Jim’s main reflections was: Is the Agile Manifesto’s statement “Individuals and interactions over processes and tools” still as relevant today as it was when it was first coined the 90’s?
We all know processes are absolutely necessary, because without process, things can become very chaotic! Any new Agile team that hits the ground running and doesn’t form the necessary team processes will understand how painful this feels. However, Jim also highlighted that having too many processes; especially “canned systems/processes” can be very constraining! For example, how many times in Agile teams has a discussion about the Minimum Viable Product (MVP), and the strict enforcement of it, killed off any new idea that came into the team, or stopped work as soon as the MVP was delivered? It almost seems like a lot of unnecessary rules are put in place simply for the sake of following the Agile ‘process’, though it doesn’t sound very Agile to me. Being this strict on your processes is a killer to creativity and progress, and as such, Jim explained that we need to embrace “adaptive processes”.
Adaptive processes and systems are put in place to actually help us deliver great things and deliver them better, instead of us having to stop and ask: “Am I doing this right?” It’s also encouraged that we change these processes whenever necessary
Next, Jim moved on to explain how Kanban can be used very effectively to adopt an “adaptive process”. Jim summarised Kanban into two key points:
- Visualise your work
- Track cycle time
Now this may sound simple, but there are a lot of finer details involved with these two points which can actually be hard to implement. What I took away from the presentation is to do what makes sense, or what you can implement right now, and then don’t be afraid to change it if it fails to work as expected.
Visualising your work is the first point of Kanban, to which a lot of people in the Agile world would say: “Well, of course!” But what is required to do this within Kanban, and why is it so important?
We work in software development and the knowledge domain, and therefore much of our work happens in our head. It is not visible. We cannot see it. Typically this means that we take on too much work and spread ourselves across lots of different things, generally because we can’t see the overall picture. We tell ourselves that we’ll be effective working in this way. Which is, well… very wrong!
The chart below explains this simply, and highlights how much wasted time and effort there is when we over-multi-task (and not just on projects, but on cards as well).
Visualising our work also provides a mechanism for teams to have a shared understanding of what is being done or worked on. And this is why Kanban encourages visualising our work, as we can better manage what we can actually see. So what are the more practical ways of doing things? Remember that you don’t have to adopt all of the techniques at once, and how it works can, and should change over time in order to be adaptive.
1. Have a story wall with cards for everything the team is working on:
- There is no set structure for the columns you need to have; just do what makes sense for your team.
- If you think the work you are doing doesn’t fit into how your board works (i.e. analysis or investigation), work out a way to visualise it.
- Emphasise that Agile/Kanban should be adaptive and not constraining.
2. Use Avatars to highlight who is working on what cards.
3. Set up your story wall so that it allows for pulling, instead of pushing work:
- This includes for Analysis, Testing, UAT, etc; not just Development.
- In Kanban you’re looking for a continuous flow of work through the wall, but pulling work is the first step.
4. Apply Work In Progress (WIP) limits, either to the entire wall or individual streams:
- This is probably the hardest to do, because we typically choose to ignore the WIP limits. We think we know better than the WIP limits. Who has seen a wall with a WIP limit with more cards than the limit? I know I have, and this is how my current wall looks. Something for me to look into and fix!
- WIP limits allow us to avoid context switching, because we don’t have as many cards to focus on.
- WIP limits also allow us to calculate Cycle Time.
Cycle Time is a way of measuring how long it takes (using empirical data) for work to flow through our wall. Using Cycle Time in this way is proven to be more accurate, as it uses historical information to calculate instead of ‘guesstimating’ in advance. Jim spent a bit of time explaining how unreliable upfront estimation can be. His best analogies were:
“We spend all this time explaining and justifying that Story Points are not a measurement of time. But then we just convert that into a Burn-up Chart, which is a measurement of time…”
“We perform work on stuff we can’t see and we work on inventive things. Therefore we’re bad at estimating. Sure… we might be right with our estimates 80% of the time (in very rare scenarios), but what about the other 20%? We get this dramatically wrong, and this is what pushes out timelines on projects.”
Jim didn’t go into the details of how to calculate Cycle Time, and so in order to do the topic justice, I would like to conduct additional research and prepare a separate blog. However, I will state that it is not as simple as putting dashes on a card and averaging how long it takes for each card to be completed. Stay tuned for a future blog about Cycle Time!
All of this process material sounds great – and it is, when used effectively and adaptively. The whole point of Kanban is to confront us with the ineffectiveness of how we sometimes work and what our process is, so that we can fix it! One of the quotes from Jim gave during his presentation really resonated with me.
He said: “There are always going to be aspects that we can improve on with our process, and this is where Kanban can help. It’s not the silver bullet, but it helps us work out what we need to fix.”
Jim’s slides are now available here >>