So, next in the series of things that are agile, I’ll be looking at Kanban. For the longest time, I had no idea what kanban was and I would bandy the word about like I knew what I was talking about. In my head, it was putting things in a Kanban board and that was it, but it’s way more than that.
It was born in Japan, coming from the Toyota Production System and comes from a desire to minimize waste (see the previous Lean post). Kan means “visual” and Ban means “card”, “board” or “note”.
Imagine, if you will, a car production line. Any car will do, but, as we’re talking about Toyota, let’s talk about an Aygo (I think they’re ugly, but you can park them under the stairs and you don’t pay congestion charge so, whatever). Your job, on the production line, as you’ve yet to be replaced with a Cyberdyne systems robotic arm, is to put the bonnet on these cars. So, a car rolls onto the platform in front of you and you pick up a bonnet from your pile of ten, pick up a screwdriver and fit the bonnet. Well done you.
The next car rolls up and you do the same, then another, and another until you’ve fitted five bonnets. The 6th car rolls onto the line in front of you and you turn to pick up a bonnet and notice a card on the top of the your 6th bonnet. It says “Order 10 more bonnets now.” and a bonnet id number. So, thankful for a break, you pickup your card, go to the guy who makes bits of cars and hand him the card. He’s just got back from delivering windows to someone and he says thanks and begins making bonnets.
The important thing to notice here, is that he hasn’t got any bonnets for you and the last thing he was doing was making and delivering windows for someone else. He isn’t making bonnets yet, because you don’t need them yet. He hasn’t got any “in stock” because you don’t know you need them yet.
Off you toddle, back to your car and carry on fitting the sixth bonnet. The moment you’ve fitted your 10th bonnet, a trolley arrives, pushed by the guy who makes bits of cars and on it is 10 bonnets. While you’re waiting for the next car to roll onto the line in front on you, he stacks the next 10 bonnets where the previous 10 were, slips a new card in between the 5th and 6th bonnets and goes back to his cage to await the card from the next person needing bonnets (or doors, or windows).
In a nutshell, this is Kanban. When you need something, you go to the next step in your process, ask for it and someone gives it to you. You put a “kanban” in their box and they deliver what is required. It’s a pretty simplistic description of it, but that’s what it is. At any one time, there are no more than 15 bonnets in existence. This is the maximum amount of bonnets ever needed at one time and, because there aren’t bonnets hanging around, waste is reduced. What we’re doing here is limiting the amount of work in progress. This is lean; why would we need more than we can actually use?
In software development, the Kanban “visual board” is just that, it’s a board you put somewhere with your story cards on it. Because software development doesn’t generally involve bonnets or doors (but it does involve Windows *shudder*), we don’t need to have cards placed between things to be found by our workers. Instead, we put eveything on our board. How your board looks is going to be up to you. Afterall, you’re the owners of your process, right?
When constructing your board, make sure you put a column for each different state, or step that your stories have to go through. Bare in mind that you’ll need a column for the status of the story; from conception through to done. For now, we’ll ignore the idea of ScrumBan, so no tasks, or sprint backlog. I’ll come back to ScrumBan in another post.
So, you’d have a column for your goals. I’d like to coach teams to work to a three month release window. The goals you’ve set for that three month period, should be in the first column. This is for information and just limits “thrash” (as used by Arlo Belshee).
The next column might be a new column. Like our bonnet guy, you might want to limit this to 10. Your mileage may vary though and you’ll want to try out different numbers seeing how you go. From the new column, your story might go into a requirements, or honing phase. You should apply a Work In Progress limit (WIP Limit) here too. To start with, try half the size of your New column WIP, so, in this case, five. This column is where your product owner would clarify what the stories mean and write the acceptance criteria. Perhaps do mockups, or at least write a document describing the interface or requirements.
Next up would be a “Development” column, the WIP here could be three, again it will depend on the size of your team(s). After that, maybe you’ll have a review, test and done columns, each with their own WIPs. The point here is that your board is unique to your process. Kanban isn’t a process, Kanban helps you highlight your process to reduce waste and spot bottlenecks. The great thing is you can introduce Kanban and it doesn’t threaten anyone or anything. You still do the same thing as you were doing before, process wise, it just forces you to have a visual representation of your process, and this is where it helps you cut out the chaff. Run your Kanban board for a while and take note of what happens. Soon your bottlenecks will be totally visible, if you’ve always got three stories in your “Test” column and the developers can’t move onto the next story because they can’t go over the “Test” WIP limit, then you know the bottleneck is with the testing.
If the board looks like it’s running well, but something is still a bit off, then perhaps be a bit more granular with your columns, can you split the “Requirements” into gathering and documenting? Or can you split the “Test” column into “automated” and “regression” columns?
Soon you’ll see where your bottlenecks are and you can fine tune your process to reduce waste. Record your progress now and after you’ve fine-tuned to see whether your changes were successful. Agree with your teams and the powers that be you’re not going to make huge, sweeping changes overnight. Help them understand that, now you can see the process, you can make gradual, incremental, evolutionary changes that means everyone keeps their jobs, but the process get’s better and creates less waste.
According to Wikipedia, this stuff can be broken down into four core components, I agree with the breakdown, but I’ve provided my own examples:
– Visualise the workflow (but it on a board!);- Limit Work In Progress (stop doing so much, only start when you’ve finished and don’t have waste lying around gathering dust);- Mange Flow (Make sure you’re recording your changes and the impact they are making so you can prove whether your changes worked);- Make Process Policies Explicit (Stick to the process on the board. Anything you do that isn’t written done but done “because that’s how you do it” should be written down and shared, some people will go “Oh, THIS is how we do this? Great!”);- Improve Collaboratively (Improve, yes. Do it with your teams, yes. Then read some sciency books about the Theory of Constrant or the Lean Economic Model … or don’t, your process won’t suffer!).
Remember, Kanban isn’t a process and doesn’t use timeboxes, it’s about visualising a process and using that new information to reduce any waste your process has.
Thank you Toyota.