When (& Why) to adopt Kanban

I started my career as a developers in a Waterfall Project management environment. This was also the framework I was introduced and taught in college; heck I'm also a Certified IT Project Manager Assessment (2002) form Singapore Computer Society and this dealt purely in Waterfall.

Fortunately and unlike all my colleagues and for some odd reason my first introduction to Agile Project Management was not with Scrum; but Kanban. Unfortunately this did not last long as I changed my job and just like all of you it's been a scrum world for me. For the past decade I have been using the scrum model and for the past few years I have been constantly telling myself = "Kanbn does this so much better".

One of the biggest frustration with the scrum model is the last few days of sprint where everyone is rushing to deliver what was committed to at the beginning of sprint, cause splitting user stories or carrying them over is bad practice. Why? Cause this affects the Velocity and burn-down charts.

When it comes to Scrum the 3 well know metrics are:

1. Velocity - this is the number of story points that the team will deliver in each sprint.
2. Commitment vs. Done - typically a % that shows how many stories that were committed and delivered .
3. Burn-down chart - this is a graph to show the how the sprint has progressed.

In the past decade, I have seen velocity shift like my internet connection at home and me entire career in scrum the only burn-down chart that I have seen is this:

And thanks to the Commitment vs. Done metric; I end up playing the referee between Developers and testers, cause developers are motivated to close a use story. Its a very fine line you walk as a PM when you have to choose delivery over quality.

The other issue that I run into consistently is when you have to pull a resources out of a squad/team to fix a critical bug. Ideally you fight and argue to try and push this to be in the next sprint, but then there are some bugs that got to be fixed immediately. This again affects your time and make your fail the commitment you made in the beginning of the sprint. Unfortunately this is the most used metric to evaluate success of a sprit/release i.e. look at the commitment vs. done.

At the end of every sprint/release, teams are supposed to retrospectives. In the past decade I have attended 1000's of these retro meetings, where the goal is to discuss what went well, what didn't not go well, and what should we do going forward. After the first few meetings, you start noticing a pattern which ultimately led me to believe that these meetings don't work or aren't effective.

Scrum by its nature is very limiting and requires discipline. If not, you can start noticing frustrated developers/teams which leads to low quality of work produced. At some point in time teams and organizations tend to focus on delivering in time then delivering high quality products.

Kanban

Despite Scrum being the current #1 agile framework, Kanban is becoming more adopted over the years. I tend to work on Kanban (if given an opportunity) and my experience so far as been nothing but positive. Given the fast changing landscape of technology and the fact that there is something new everyday, adopting Kanban has helped me and my team tremendously to delivery quality product (almost) on time.

Kanban was first introduced by Toyota back in the 40's where they had a classic assembly line in place which are supplier driven designed for MAXIMUM efficiency. To have a more customer driven approach they optimized their engineering process.

When Toyota brought that idea to it's factory floors, teams (such as the team that attaches the doors to the car's frame) would deliver a card, or "kanban", to each other (say, to the team that assembles the doors) to signal that they have excess capacity and are ready to pull more materials. Although the signaling technology has evolved, this system is still at the core of "just in time" manufacturing today.

Kanban does the same for software teams. By matching the amount of work in progress to the team's capacity, kanban gives teams more flexible planning options, faster output, clear focus, and transparency throughout the development cycle.

I like this image from Cuelogic that shows the difference between Scrum vs. Kanban.

Kanban offers flexibility, however; one has to be disciplined with this methodology as well. As Kanban does not force you to have a commitment every two weeks, Kanban has a set of metrics that can be sued to evaluate a team's performance.

1. Throughput is the number of user stories delivered for a given time range. For example, if your organization does a release every 6 weeks, you would look at the # of user tires that made it to the release.
2. Cycle time is the number of days it takes for a user story to go from start to deliver. Most uses confidence intervals and the most common measure is 85% confidence.
3. Cumulative flow diagram is used to visualize the flow of user stories for a given team.

Kanban is simple and most importantly flexible. You can mould the model to fit it with a process that works for you and your team. Unlike scrum Kanban has no necessary rituals or activity. However, there are a couple of rituals that you can borrow from Scrum:

1. Story Estimation - this can be helpful cause this allows all of team members to discuss a story which allows you to determine the scope and size. Do it with your PM.
2. Retrospective meetings are one of the most important meetings for a team. It encourages you to improve constantly and with Kanban it allows you to tweak your workflows to make sure quality is always high.

Finally, this is a perfect image that sums up the differences as well as something that you can use to determine when to use scrum or Kanban model for your next product.