Kanban in Real Life

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