Kanban is based both on Lean and the theory of constraints. It was created by David Anderson about five years ago and is achieving an upsurge in interest . Kanban is based on a few basic premises. The first is that requiring an organization to undergo a large change at one time in order to start being Agile may be counter-productive. Telling people they have to adopt new roles and work in a different way often creates fear in those being forced to change. They feel devalued as they are told their former methods of working are to be abandoned.
The first few years of the Agile movement saw Scrum adopted where teams already existed and the developers/testers/analysts wanted to change. Many going the Agile route no longer fit into this class—perhaps another reason for the difficulties encountered. Many Agilists will tell you that the way to overcome this high amount of change is to hire a trainer and coach. However, an alternative approach may be to understake a smooth transition while starting down a road that gets you to your ultimate goal in a less disruptive manner.
The essence of Kanban is to start where you are and do three things:
- Make agreements with your stakeholders as to what your goals are and how many projects the developers will be working on at any one time.
- Create visibility into the development process by mapping its value stream. A “value stream” is the series of steps where an idea goes from concept to being defined to being built to being deployed to being used. Then have explicitly defined policies of how work moves through the value stream. This is extremely important because it enables management to see how their actions affect the team and because the discussions around these explicit policies greatly accelerate learning.
- Manage the amount of work in progress (WIP) being done at each step. In particular, the team (and management) needs to look for places where the work gets backed up and then figure out how to unblock things. This clarity provides insights into solving the impediments the team hits.
Corey Ladas incorporated Kanban to the Scrum framework to create a hybrid called “Scrumban.” This has been a useful method for helping Scrum teams to adopt Kanban methods.
Achieving Business Agility: Where to Start
So, where do you start? It depends on where you are and where you want to go. My experience is that trying to start an Agile adoption through a team pilot project is not always best. Like that car’s engine, the team method may not be the problem. Even if it needs improving, you will always be better off by looking at the entire context within which software development is done and then choosing what to improve. Here are two recommendations:
- Begin by looking at the entire value stream. Where are the challenges, what needs to improve? This does not mean you are committing to changing more than the team, but doing so will provide insights that will ensure team progress translates to business progress, to business agility.
- Let the teams involved choose between Scrum and Kanban. They will intuitively know which is best for them. Part of respecting people means to allow them to choose how they do their work—within the context of the business, of course.