Lean software development is becoming a new buzzword. More and more articles, books and discussions around lean and software development popped up last year. People are using new terms like Kaizen, Kanban, Muda, Pull System, etc. Well, this is great. New thinking about software development stimulates new ideas and new solutions to old problems.
Push, Pull, Kanban
Kanban is a very popular buzzword in agile community and in this post I will try to combine various applications of Kanban for software development. In general, Kanban is a part of Pull System. Pull system determines whole supply chain. How many screwdrivers we should produce next month? Push system predicts the quantity based on history data and market parameters. For example, we predict that we need 10000 screwdrivers next year and will produce 10000 screwdrivers. Who cares if one half of the screwdrivers will be unsold till the end of the year? The plans for next year will be corrected, but unsold screwdrivers take store space and money. Pull system produces just required amount of screwdrivers. In ideal life we find a customer, produces what he needs and sell it. Anyway, Pull system reduces inventory.
Kanban is a sign or a signal in the development/supply chain. It activates some process. For example, you have small shop that sells screwdrivers, small warehouse and small plant. Imagine that each screwdriver has small kanban card on it. If a lucky houseowner purchased one screwdriver, the card returned to warehouse. It shows that one screwdriver should be delivered to the shop. The screwdriver delivered, but free kanban card returned to the plant. Plant management knows that one more screwdriver should be produced. They produce it and deliver to the warehouse. Thus customers’ demands rule the whole cycle.
How it can be applied to software development? I think there are several applications. One-year-long project plan is a push system. We expect to sell all these features in the next year delivery, but it may happen that customers will need (use) only one half of them. “Why the hell you add Blue Ray support? This is plain dead thing!” There situations where one-year-long plans works. If customers demand is defined and persistent, you may do that. It means that customers do not want to change anything in product scope next year. I don’t know industries where it is true, but I asume they may exist.
Iterative development and product backlog is a pull system. If the item is in the backlog, it represents customer’s demand. But customer is free to remove it anytime, thus changing the demand. This is a high level kanban (product kanban). If item exist in the backlog it is a signal that it should be implemented.
During iteration development kanban rules Implementation/Testing activities. For example, testing team may take implemented user stories and start testing. The most popular way for this kanban is a simple whiteboard with several columns (Not Started, In Progress, Implemented, Tested). Each user story is a small sticky note. Initially all user stories are in Not Started column. When user story is done by developer, he put the sticky note to Implemented column. And that is the sign for testers.
You may think out different ways though. For example, when user story is implemented, loudspeaker in the testers room shouts “User Story As an Admin I want to moderate people comments implemented” each 5 minutes until somebody takes this story for testing. Another way is to take story card, crouch to testers room and put it into implemented user stories stack behind tester’s back. You got the idea. Testers should be able to check what is available for testing anytime.
Kanban board may work for complex process without problems. Developers see what to take for implementation, testers see what to take for testing, technical writers see what to take for user guide update, customer see what is ready for check or release.
Software development differs from manufacturing significantly. The plant produces looks-alike screwdrivers. It can have robots and sharp process to produce stuff. We can’t replace developers with robots. Each feature is unique, each user story is unique. We can’t create detailed process, software development needs innovations, researches and a-ha! moments. Software development is a complex adaptive system that works on the edge of chaos and can’t be ruled by complex procedures and instructions. Complex rules lead to dumb simplistic behavior, we can’t apply such processes to software development.
It seems I went to far. OK, back to kanban. Signals in software kanban should be different. It is not enough to meet a tester and put black label (or card) into his hand when user story is ready. Tester should know what exactly user story is ready (only screwdrivers are the same!). The kanban card should contain at least user story name or ID. That is why in kanban board status coded by column/story combination.
Alternative is to use labels with different colors for each user story. For example, yellow label for implemented, orange label for testing. But each label should have user story ID (or name) on it. You may give labels to developers and testers and they will stick them to user story when required.
Maybe this method worse than usual board, but I just want to show you that there are different ways to kanban in software development and you may be creative to generate better ideas.
If you have distributed teams you will have to use web based kanban. I am not aware about online tools that provide kanban board. If you need just kanban board most likely you will have to create it in-house. There are tools with Task Board (including TargetProcess), but it is not the same. Task board shows task statuses and from tasks it is not clear when the user story is ready for testing. It can be used as a signaling system, but with less success.
A nice side effect is that Kanban board helps to identify problems in agile development process.