People in the industry often perceive Scrum as a framework used for developing a product, while Kanban is exclusively used
for either user or tech support. I tend to disagree, as Kanban can be a great solution for many development teams,
especially those that are struggling with their process.
Kenneth S. Rubin considers placement of Scrum and Kanban in the
Cynefin framework in his book “Essential Scrum: A Practical Guide to the Most Popular Agile
Process”. Rubin argues that Scrum is particularly well suited for Complex domain, whereas Kanban is good for
Interrupt-Driven work environments.
Some background on the story... Developing a product that is already in production is a tricky business. The life cycle of software
after the release often tends to be Interrupt-Driven. Sometimes, a client needs an urgent feature. Sometimes,
iOS user gave your application 1-star review because of a new bug that has just popped out. You simply need to
take action right away. Regardless of how complex the product is, in reality, most product development lines
do not have dedicated teams for both maintenance and development. Instead, they have just one development team
which needs to handle the interruption.
I have seen many Scrum teams struggle with this, as fast-paced products sometimes don't even have a week ahead of predictability.
If you already have a sprint underway, chances are that you'll take something of equal size and lesser priority
out of the sprint and replace it with something that just jumped in. That ultimately, because of the lack of
predictability needed to improve Scrum properly, leads to Scrum losing its value. If you are not in a sprint
and your current process is not yielding needed results, you should definitely consider Kanban. Kanban is great
because it is easy to implement over existing practices and brings transparency into the flow very quickly.
Before starting, please bear in mind that Kanban is not a golden bullet for the software development project. Although its
flow reflects agile values and provides multiple benefits, advanced software development practices like Continuous
Integration, Peer Reviews, Pair Programming, and Test-driven Development are essential for large scale organizations
in order to deliver high-quality software.
Kanban is not as fully encompassing compared to Scrum/XP/DA as it is silent regarding software development practices. It
has only 3 prescriptions:
1. Visualize your workflow
2. Limit Work-In-Progress
3. Measure flow to maximize the output
Visualization
Let us discuss the benefits of this. First, visualizing your workflow is a must-have for
any managed software development project, and can easily be done with tools like Jira or Trello. The most basic
Kanban boards tend to have three states:
1. To Do
2. In Progress
3. Done
In real life software development, chances are that you will soon realize that you are missing a few
more:
1. To Do
2. On Hold
3. In Progress
4. Deployed To Staging
5. In QA
6. Ready for Release
Why On Hold? Since we are limiting Work-In-Progress, sometimes, a software engineer might start working
on something, but needs more info in order to proceed with the work. As we do not want our engineers to sit idle,
the best idea is to put a ticket On Hold while the engineer works on the next thing in the queue.
Deployed to Staging, or however you want to name it, depending on the development platform, is really
handy because it gives an overview to QA team that the item is ready for them to start testing it. Depending
on the testing results, tasks might move from QA state to To Do state if issues are found or to Ready for Release
state if the task meets the requirements to be released.
Limit WIP Limiting Work-In-Progress is also important because all you need is a quick look against
the board to see the overview of current progress. If it seems like the engineer is solving multiple tickets
at the same times, that means that the tasks are too massive and you might want to consider using something like
INVEST principle.
Some teams tend to adjust to a higher number of Work-In-Progress items, but I tend to advise against that. When
you really think about it, engineers always work on one task, as engineers usually tend to come with no more
than one pair of hands and one pair of eyes.
Measure and Maximize
Measuring the flow and maximizing the output is about removing unnecessary waste.
The first place to look is usually the impact of meetings and development practices(or lack of same) against the value
your developers are creating. Anything that is not creating value for your product should be eliminated least painfully for the team.
The next step is on you. There are plenty of good resources out there, my first suggestion would be ‘Agile Project Management
with Kanban’ by Eric Brechner.
*Disclaimer for some of the Agile enthusiasts: In this post I have consciously been using Kanban with capital K instead of lower-case k. I have done that on purpose in order to avoid possible confusion.