Kanban For Software Development | {"Mat's Random Thoughts"}

There are many ways to develop software using Agile techniques. Kanban is a recent entry into this and has some interesting dynamics going for it. Its great to see new ideas from across the industry being applied to software development. Not sure if Kanban is the final answer though – save that for my last paragraph.

In SCRUM we break down a release into small sprints. Each sprint begins with planning and ends with a demo and retrospective. That sounds reasonable until you start facing some challenges.

Teams struggle to fit development, system and acceptance testing into a single sprint (1-3 weeks). Especially true in large organizations that are struggling to implement agile in a silo’ed environment.
Some folks who are really good at what they do, finish up tasks earlier and may have to face idle time (sometimes they can help the laggards).
Folks who are new or just slow can put an entire sprint into jeopardy.
Team dynamics cannot be predicted. Early planning estimates can go completely haywire. No team remains static and each person in a team brings a different level of expertise to the table. Thus making it harder to predict estimates.
What if you have a development team that speeds ahead and is done halfway through the sprint. They have to wait until the next sprint planning to figure out what needs to be done. Or they pick additional tasks from the backlog and hope they can stay ahead. But now the testing team has more work than they anticipated.
What if the testing team is done and is waiting for additional tasks which they will only get at the end of the next sprint.

Now all of this can be addressed in SCRUM with some degree of success. None of these are show-stoppers to me for using SCRUM. But it begs the question – is there a more natural way to do development.

My Ignorable Rant: Those who go about speaking about Agile w/o ever having written any significant amount of code just do not get it. Writing good software is hard and is unpredictable. You cannot box someone to 1-2 weeks and have a cookie-cutter approach to development. Development is an art that is perfected over years – alas often not seen that way anymore. Writing code is not about taking things off of the shelf and assembling as you go. We have not reached that stage yet. There is a lot of thought and rigor that needs to be put in to build good code.

Software development with Kanban attempts to break out of the current model, breathe some fresh air into all of us and yet stay true to Agile principles (see the AgileManifesto). Kanban (Japanese for Visual Cards) in software development is inspired from Lean principles and the Toyota Production System. Avoid waste. Kanban specifies creating a set of states (vertical columns on a board) – each representing a certain state of development. A work item flows through the states from left to right. Work items can go back into the previous states if needed. Lets define a few states for us:

I have added quite a few states here to depict a slightly more granular level of detail. Now the only thing Kanban requires you to define is the WIP or the Work In Progress Limit. The WIP Limit is a maximum count of work items that can be allocated into any of your states. You can also define a different WIP Limit for each state. This can, for example, reflect ground realities such as skill gaps in teams and simple resource constraints. For example you have 5 developers and only 3 testers in system testing. So you can decide that at any given time only 10 work items can exist in the in-progress state and only 6 in the system testing state. This allows for some flexibility in case someone finishes a task earlier and needs something else to work on.

The backlog contains list of things to be implemented. The story queue is a prioritized set of stories from the backlog. The backlog is only an unsorted holding area. Within each state we can further subdivide into horizontal sections to divide say those items that are being worked on vs. others that have not yet started.

Work items progress all they way from left to right. As the WIP limit is reached no more items can be added and the reverse holds true when the WIP goes under the WIP Limit for that state. If the next state is full then the folks working in the current state could lend a helping hand to clear their queue. Developers can put on tester hats for a few days to help clear out the testing state and reduce the WIP there. This level of collaboration is critical otherwise folks can be sitting idle.

Gone are the sprints or the definite structure that SCRUM gives us. Its all about getting work done from a prioritized work queue and how much work capacity exists within the team.

Now this may remind you of a pipeline process or an assembly line. And that’s exactly where the similarity ends since developing software is way different from manufacturing on assembly lines (see my earlier rant). But the underlying principle of avoiding waste holds true.

I do think that successful application of Kanban in software development projects require a higher level of team collaboration and management support as compared to say SCRUM. Teams have to change the way they work together. As mentioned earlier if the testing team is in a crunch, the development team jumps in to help out a little. Thereby allowing the assembly line to keep moving. Players throughout the states need to realize that work can come in anytime but will never exceed their current capacity.

So does this mean we have to choose from SCRUM or Kanban. As always – it depends on your situation.

In the beginning I said “Not sure if Kanban is the final answer though – save that for my last paragraph.” Why did I say that. If you have not read my rant, go back and read it. Thats why.