Using Kanban for Scrum improvement

…. sprinters believe that — someday — somebody will run the 100 meters and the clock will read 0.00

Before I start it is important to note, with Lean/Kanban, we are entering an area trod by Agile/Scrum, and people’s need to have abstract generic solutions. In order to properly utilise these processes, requires thought and planning.   My first experiences of Kanban was on a re-factoring projects, and it seemed as if Kanban approach was ideally suited to a project that was likely to uncover surprises. But scratching beneath the surface I realised it was a far more efficient project management style, that mirrored general Lean software development principles.

There are also other methodologies, but I consider Agile to be closest to Lean/Kanban approach.  There are other methodologies out there, but Lean/Kanban feels especially relevant in the field of web application and services development. In the obsessiveness over Waterfall, it’s easy to forget the others that apepared such as RUP. One of the main differences between Scrum and RUP is that in RUP you get too much, and you are supposed to remove the stuff you don’t need. In Scrum you get too little, and you are supposed to add the stuff that is missing. With Lean and Kanban this is even more true – but too little?  I would say any competent manager would be able to understand the principles and how to apply them in their area.

I am actually trying to drop references to Agile recently, as the Lean ethos not only encapsulates Agile, it drives it further by simplifying the objectives.   Less chance of misinterpretation and more clarity.  A lot of what I read on methodology (or even what I write!), feels too granular to solve overall problems.  If you are getting in company culture area, then the larger the company, the more exponential the resistance will be.  Lean and Kanban approaches have come from Japan, and this is a key barrier – and also shows how difficult other countries will find them.  Altruism, team-work and group cohesiveness are all areas greatly stressed within Japanese society – and that includes within the workplace.  This is not typical of many countries, especially those in the West or those with Western ideals.

The Kanban method is based on three foundational principles:

1. Start with what you do now.
2. Agree to pursue incremental, evolutionary change.
3. Respect the current process, roles, responsibilities, and titles

Kanban is a method for advancing incremental, evolutionary changes in IT organizations, which limit work in progress (WIP) and create a pull system where new work can only be started as existing work is completed. It is very effective way to manage tasks, but to go Kanban without any further thought is simply treading well-worn paths of mistakes. The general aims above are misleading in that they don’t indicate the level of detail and planning work that goes into changing the way people work. Kanban has been used in manufacturing for many years, and an important fact to remember is manufacturing produces products, with Kanban used as ongoing improvements to the process of producing the product. The path to product is less convoluted than development process, less less fraught with internal politics.

Scrum is a framework for building product that is based on The Toyota Way. Scrum splits the Chief Engineer role in manufacturing, with a Product Owner and a ScrumMaster. Scrum is a standalone project management methodology (or framework). Scrum is more than “Iterations” – Kanban does not have iterations while Scrum does. While that is a difference, there are at least 4 other more important Kanban differentiators to consider.

Manage Work in Progress (WIP)

Core to Kanban is management of the amount of Work in Progress. This enables the team to stay focused and avoids creating new work caused by delays between the stages of work.  A common Scrum impediment is having many things still in test at the end of a sprint.

Visibility of process, not merely of results

Management can see what the team is doing to achieve their results. This helps management see how teams are doing and enables them to play a more active role in removing their impediments.

Include Management

Management should respect that the team is doing their best, but understands that sometimes teams don’t see all the things they need to do. Scrum, on the other hand, tells management to trust the team – to never interfere or intrude.

Extend the Value Stream before the team starts

By including management, Kanban has a direct impact on the product management, and has avoids the development team(s) becoming overloaded.  Senior management can easily appear unreasonable, but usually their demands are based on what they know, not necessarily what is happening.  Including them continuously means they can make better judgements, and they can remove business-related impediments.

Although Kanban teams don’t need iterations, it doesn’t mean you aren’t allowed to have delivery dates (I don’t think you would get many clients).  It is important not to go with the hyterical plea of a lot of Kanban-ists that there is no Iteration(Sprint) – at the heart of Kanban and Scrum is acknowledgement of a continuous process, regardless of milestones in place. And it is this that was general common failure in Agile implementations – failing to apply to Agile ethos either development or management, or both.    The more rapid delployments could still be viewed as Iterations (though very short ones), and it will enable you to update your client as to progress, with confidence.   You are also more likely to have an up-to-date versions to demo.

For close on a decade,  Scrum has provides UK companies with what they perceive as a safe IT project management. Business care less about the development process, and more about the delivery schedule and visibility of progress.  Scrum does provides a foundation of transition, and if you have got Scrum right, why not try and introduce some added Kanban.  Typically this combination is called Scrumban, to differentiate from standard Scrum which does not explicitly manage WIP and from Kanban which does not use iterations.  How much you take of either is up to you, and what your company culture can accommodate.  With Kanban, you can start where you are and slowly tune up the rate of process change by managing your work in progress limits.

Whether Scrum or Kanban or both, it going to be hard to change things at senior management level in a business. Both Scrum and Kanban advocate review and improve process all the way to the top of the chain.  For a production line that’s logic, for a busines that is a lot of office politics to cut through.  And in order to effectively use Kanban you need to work out your cross-functional team structure, identify individuals and skills and how best to manage them.  Identifying skills within the team enables you to effectively plan and assign tasks.

The important thing is that people keep their roles – there is a lot of misinformation around this, but how could a Project Manager, Business Analyst, Product Owner, Scrummaster, TESTER, etc. ever be of no value?  Restructure the processes and rules, then worry about individuals’ value afterwards.  Some people will end up shining is a changed approach, some will not suit it, but largely people go with the flow. In the drive to “eliminate waste”, don’t be surprised if that sometimes means people – enthusiasm for the process, can negate lesser skills, but resistance to change is means there is already point of weakness.

Related posts:

1. Scrum with Kanban
2. From Scrum to Kanban
3. Kanban applied to Scrum (video)
4. The illusion of the Scrum “safety net” with Kanban
5. Kanban, the new Scrum? Please, no …