Episode 143 - 11 Mar 2020
Previously… I got a coffee cup pushed in my face
Today… we’ll uncover 4 kanban principles, and look at how that they can help YOU in your Agile development team. Whether you’re doing KANBAN or - and this might surprise you - SCRUM.
Things started so well. So simply.
A lone barista, bestriding his humble coffee shop like a colossus(!)
Doing everything his defined process:
Order Make deliver
Adding a dedicated order-taker didn’t seem like a big deal, but with specialisation came the need for orchestration.
Key to that was the buffer:
In the coffee shop, this area of counter On the board, this column. The grey colour a reminder that no value is added here.
Waiting. A waste of sorts.But it’s a price that we willingly pay to switch the system from push to pull.
Let’s step out of the coffee shop for now, and make our board a little more development-oriented.
How about a defined process of:
Development Test Release
Now, if I was working alone, the board would work as is.
But working as part of a team. A team with specialisation: developers, tests - even dedicated deployment personnel - we’re going to need to handle those hand-offs.
That means buffer columns.
And again it’s with a heavy heart… that I colour them grey - to remind us that no value is added here.
Let’s give this team some work to do:
Into Development. Typically the longest time. Into Dev Done and immediately into... *Test”. hopefully that won’t take too long. Into *Test Done”. And into “Deploy”.
In this team when Deployment is done, the task is DONE. (Which is why I haven’t splt the Depoly column.) Some thought went into this, you know!
How long did it take to get from end to end? Around 30 seconds.
There are 6 people on this team, so we can do better.
Oh. And let’s add in some Development Environment-appropriate music!
Looks like this are popping out every 5 seconds or so. That’s 12 per minute.
That’s a useful metric. But there’s another that’s arguably much more important: the time it takes a single item of work to get from end to end.
Best case - as we just saw - is 30 seconds.
But what if the board looked like this?
Imagine how long it would take this pink card to make it all the way across.
Seriously. I really need you to imagine it. I am not animating that mess!
We already know that the cure for this: it is to impose Work In Progress (WIP) limits.
So let’s do that.
And again, keep your eyes on Mr Pink.
Took.. sure, a good bit more that 30 seconds to make it across the board - about 20% more.
But way less time than this [the crowded] case.
This is an important point: work in progress limits don’t just limit work, they limit time: the time it takes for one item to get all the way through the system.
Why is that important?
In the coffee shop, wait too long and the customer may change his mind.
Can something similar happen in development? Of course it can!
Let’s take the WIP limits away for a moment. And go crazy with the Post-It’s.
What if something comes to light that means that all of these have to be re-worked?
Or we learn something that makes ALL of these irrelevant?
All that development time that went into there items down the drain. A waste.
CLearly those WIP limits are a big deal.
And before we move on, I’m going to make a small optimisation.
As both of these columns belong to the Dev Team, instead of the Devs having limits of 4 and 2, I’m going to impose a shared WIP limit of 5.
I can’t use the red lines any more, so I’m going to replace them with a number at the top.
Similarly for Test: instead of limits of 3 and 2, a shared WIP of 5.
Did you notice that I just reduced the WIP of the system by two?
By now, you know that that should be a good thing. All other things being equal, it will get work across the board faster.
Of course, all things are not equal: reducing WIP is one of those things that’s simple, but far from easy.
Let’s throw a spanner in the works: Development is at capacity. And that capacity is all in the grey.
The entire Dev team is stuck. Blocked.
This might indicate that we need to beef up the Test/QA team.And if this situation happens a lot, that’s probably a good idea.
But that doesn’t help up today. And we have a problem right here, right now.
What should the Dev team do?
Pick up another ticket? Do nothing? Do something else?
The WIP limit… prevents the first option. And that’s by design: doing nothing is, it turns out, a much better option!
You may remember that we came across this situation in the coffee shop.
We talked about Dr Who here… starting to stall.
It was better for the system as a whole for him to be fiddling with his Sonic Screwdriver than taking more orders.
But what about option 3?
Was there something else that Dr Who could have done?
Something more… productive.
Indeed there was. As many of you suggested.
He could hop in the Tardis, travel back in time.. Just kidding.
He could get on and brew a coffee!
Does he have to be as fast as Mr Barista. Not at all!
Of course, he’s still going to be expected to produce a quality brew.
We’ve talked a lot about specialisation and, in turn, specialists.
Now we see the benefit of those specialists ALSO having cross-functional skills.
Jumping back to or board, can you see that the best move for the Developers is to do a spot of testing?
And just like that we’ve tripped over a third kanban principle:
Focus on flow
Not a focus on the Dev columns. Not a focus on the Test Columns. Not a focus on individual columns at all. But a focus on keeping the things moving.
A focus on the flow.
What’s next for this team?
Well, that’s up to the member of team to discover over time.
They might further reduce WIP. They might find new reasons to specialise. Or they might decide that a specialisation no longer serves them. No longer pays them back for the additional Work In Progress.
[What else might they do? Let me know in the comments below.]
Kanban teaches us that this is just the beginning; the beginning of a journey that never ends.
A journey of continuous improvement aka Kaizen.
Since we first walked into the coffee shop two episode ago, we’ve seen no shortage of kanbans (objects):
Post-Its Coffee cups even - somewhat controversially - people.
And we’ve uncovered 4 kanban principles:
Visualise the work Reduce Work in Progress Focus on flow Continuous improvement
Agile Framework-wise, we’ve developed a board that would serve a team “doing Kanban” (the agile framework) well.
And it would serve them well because its design arose from those kanban principles.
Which is an important point:
If you are currently “Doing Kanban” and are not getting the results you’d hoped for, the chances are that you’re suffering from a lack of application of the KANBAN principles:
“Doing Kanban” is no guarantee of applying kanban principles. And it’s the principles that make Kanban work.
And while we’re on the subject of Agile frameworks: if you are currently “doing Scrum” and are not getting the results you’d hoped for, I have great news for you: the kanban principles can be applied to Scrum too!
It’s true! There’s nothing in the Scrum Guide that forbids you from
Visualising the work Reducing Work in Progress Focusing on flow improving continuously!
If only there was a step by step process to help you with that.
The great news is that there is! You can find out about it in the very next episode.
Watch "Putting the 4 kanban principles to work" on YouTube.