Putting the 4 kanban principles to work
28,457
Published 2020-03-11
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/webinars/p-and-p?ref=y…
= = = = = = = = = = = =
-------------------
143. Putting the 4 kanban principles to work
#kanban #agile #DevelopmentThatPays
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. In the coffee shop ---- 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. A board fit for a development team ------ 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. To work ------ 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. Scale up ----- 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! Limiting Work in Progress ------ 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. Waste ------- 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. Shared WIP ---- 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. Focus on Flow ---- 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 stu
• Putting the 4 kanban principles to work