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.
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.
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.
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.