I got another email from a former client that I wanted to answer here on the blog. In fact, in this instance, I also got the same question during a Lean Coffee discussion at a current client too.
Without stating the whole email the questions were a little bit like this:
With kanban - isn’t there a risk that you lock in and cement the different parts of the board?
Also, are we not risking to focus too much on the efficiency of the individual steps in the workflow?
Since the board clearly shows bottlenecks in some areas we risk putting in an effort to solve that and then just move the workload to another place in the workflow.
and then in the lean coffee
I don’t like those columns - it looks like a waterfall. I just want DOING to show that we are working together.
Well.. thanks for your questions. My answer is Yes, Yes, Yes and Ok. … but also No, No, No and Why.
Let me explain.
Before I answer those worries and comments I need to step back and explain a few things in my usage and understanding of kanban. You may not skip this part as the rest of my answer heavily depends on this reasoning.
What is kanban, really?
First of all; kanban is a method to improve your work. It’s not dictating how you do work. It’s simply showing you opportunities for improvement, that you can choose to act on or not.
Very simply kanban can be described in 4 simple principles:
- Start where you are
- Make your work visible
- Limit work in process
- Help work to flow faster (through the whole value chain)
As you can see these simple principles are applicable to almost everything we do; from a personal to an enterprise level (limit number of simultaneous projects, for example). I’ve applied kanban, with success, to everything from IT development teams, through my kids TV-time to managing a hospital in Indonesia.
Yes, that is kanban with a lowercase “k”. There are other things called Kanban Method etc. but that is built on the same principles as above.
Also, adding to the confusion;
- A kanban board is a kind of visualization of the work. Usually as an array of columns mapping to the current (start where you are) workflow
- Each card could be referred to as a kanban card, or a work card.
Leading to the very confusing but syntactically correct sentence:
The purpose of kanban is to flow kanbans fast over the kanban.
But in essence:
Kanban is a method that helps you improve processes.
What is kanban for, really?
Ok, what good is that then? How will this help me?, you might ask.
Start where you are will help you as you don’t / should not do big changes. Ever. But even as we improve we should strive to do smaller steps towards … well better … What is that even? A question I sometimes surprise my coachee’s with is “If this team was 100% better in a month - how would we notice? How would people around us?”
Speaking of noticing; this is one of the benefits of visualization. Knowledge work (as we do in the IT industry) has the drawback that it is not visible. So we need to take it out of our heads and into the physical world somehow. Make a little post-it note for each item we are working on. Map these post-its in a column describing the type of work we are doing. Draw a diagram showing how we are progressing towards our goals. The sky is the limit - visualize the crap out of that work. The better we see it - the better the decisions we make around it.
(Yes it might be in an electronic tool too. As long as we all can see it where we work, I’m happy.)
Limiting work in process is the secret sauce where we introduce a little tension in the system. Well, actually just limiting the number of items in progress will make each item be completed faster, help us learn faster, make work more fun and fulfilling, improve focus, and give us more opportunities to re-decide as we learn…
but also, with a limit of how many things we are doing, something is now asking questions. Questions like:
- “out of A and B - which is more important”
- “I cannot start new work due to that pesky WIP limit - what should I do”
- “This thing is super big - it will eat up one out of our WIP limit of 5… that is stupid”
- “Ok - sure I can start this new thing if you want, but then I have to drop this other thing. That is what the WIP limit tells us. Is that ok? Can you go over to {name of important stakeholder WAAAY up in the hierarchy here} and just tell him that we are doing this other thing instead?”
Those are all made up, obviously… not really… but really made up… not…
Here’s the thing; limiting work in process and visualization will show you the problems, but not solve all of them for you. That part is left up to you and, in my experience, always contextual to the current time, current people, current organization and current opportunity.
The focus on help work to flow is the principle that drives this behavior. Flow where? Of what?
The flow of finished things (as “Thank you” from the person ordering) of things that matters and is valuable to someone. See Mike Burrows excellent definition of done
Someone’s need was met
We are all here, not to do our little part as fast as possible, but to support the flow of value (work items we might call them) from start to finish, from “Could you please?” to “Thank you - that was really nice”.
That we are testing really fast matters little if there’s a long waiting period to deploy.
Starting where you are with your work visualized and limited you can now focus on making the flow of “someone’s need met” faster. This is where we start to change our process, ways of working, cooperation, organizational structure, roles, tools. EVERYTHING. But in very small steps.
No - I cannot tell you how that will look at the end. Neither can you. But you can start to discover better ways in small steps.
Will you answer my questions anytime soon?
Yes. Now, actually.
Because with that basic premises of what kanban really is the questions are easy to answer
I don’t like all those process steps - it looks like a waterfall
This is one of the most common push-back I get when we are mapping a workflow. The response is simple: the board should reflect your current ways - not my or anything from a book. I wrote a blog post on that
If you are a team of people that works together to finish work (from idea, via dev, test and deploy and followup while it’s used by customers), regardless of roles, as you might do in a mob programming team for example; then having an elaborate workflow is not reflecting how you actually work. Just have mind map for things that you have not started and a single column for the one thing you are working on.
If you, however, have more steps than “The one thing we are doing right now” in your workflow, by all means, let the board show the way you are working.
The closer your visualization reflects how you actually work the more likely you will find improvements relevant to you.
Will kanban cement my current roles?
Yes. If you let it.
Kanban only shows you how your work works, if you like. If you see problems with how the workflow, such as bottlenecks and huge amounts of WIP, but change nothing in your process to handle it - nothing will improve. Improving means changing
So if you have a board with a long array of 14 columns because your process of implementing that contract in code requires 14 steps - perfect! That is how you work today - so it’s a good visualization. Put a WIP limit on that board (“There will never be more than 15 items on the board at once”, for example) and you’re off to a great start.
But if you see problems (everything gets stuck in column 3 for example) but do nothing about it - unsurprisingly nothing will improve either.
Are we not focusing on making the individual steps more efficient?
Yes. If you let it.
But no, you should not. Anything lean or agile should aim to make the whole value chain faster. The goal for everyone is to move the work faster through all of the work.
{He used the same reasoning as above, and the reader fell asleep}.
How should we handle bottlenecks then?
Ah - this is now interesting. Let me reformulate this into kanban-ish language
What should I do when the WIP limit is hit?
You finish a work item. You want to pull new work. But the WIP limit is 4 and there are already 4 items in your column. What should you do?
Here are a few things to think about:
- Is there any work on the board that is not finished that would benefit from you helping? Do that. Help to finish work. Start from the right and see what is closest to being finished on the board. Help to finish that.
YES, I AM VERY MUCH TALKING ABOUT THINGS THAT YOU NORMALLY DON’T DO.
- Dev doing test - absolutely.
- Testers doing analyzing - sure!
- Anyone doing deploy - sure!
- Doing something you never did before? Perfect. Team up with someone and learn
- If there’s no work that you can help finish (I don’t believe you but ok - let’s play along :)), what can you do then?
- First - do not start new work if you absolutely cannot avoid it. It will, with mathematical certainty, make all other work slower. And risker. And harder.
- Second - learn something that you think will help you (and us) in the future.
- Third - do something that will help us move faster in the future. Update the build server, write a better e2e test that replaces 2 slow tests… whatever. Only rule: make sure you can drop that if we need you to help out finishing work. Pick up work that is important but not urgent.
- Fourth - take a break, my friend. Maybe get to know your teammates - who knows; you might do a better job with people you know
Conclusion
Kanban is just a tool. It improves processes by showing you improvement opportunities in the process. If you don’t change the way you work, to handle these problems improvement opportunities you will not improve either.
Kanban does not cement the roles in your organization - if you don’t let it. If anything it shows that the roles in your organization are cemented. Now - do you want to do something about that to be better? Yes? No?
Bottlenecks are things that slow down the flow of value from start to finish. The biggest bottleneck is the place where the whole system slows down. Fix that and the whole system will be faster. But then the bottleneck might have moved. By taking the focus of the flow of the entire chain you ensure that you are not optimizing parts. By optimizing parts you stand a great risk of not fixing the overall flow problem.
Let the kanban board reflect how you work now - not an idealistic process. We want to fix how we work now, not fix the idealistic process, right. You make the visualization. Make it show your work.
I hope you found this useful. Thanks for the great comments and questions.