Thursday, June 10, 2010
Thoughts on how Kanban differs from Scrum
I’ve largely stayed out of the debate comparing Scrum to Kanban or those wishing to position the techniques as rivals. I’ve actively encouraged Mattias Skarin and Henrik Kniberg who have done a very good job analyzing and comparing in their book Scrum and Kanban making the best of both!
I feel that I can add some insights that Henrik and Mattias didn’t cover - insights that have emerged while I’ve been touring the world this past nine months working with teams and agile coaches on 5 continents from small innovative startup firms to some of the world’s largest industrial and technology businesses.
At one level Scrum is presented as quite a prescriptive project management process - Sprints, Scrums, Sprint Planning, Retrospectives, Demos etc etc. The leadership of the Scrum community is anxious to point out that Scrum is much more than this - it is a framework for provoking change and emergent behavior in organizations.
Kanban is not a project management or software development lifecycle method. It is an approach to change management - a framework for catalyzing change in an organization. So it differs from Scrum in that it cannot be used as a process to get work done. It needs to be applied to an existing process. That existing process can be Scrum, or equally any other lifecycle method with which you are familiar, or something that has no name - an ad hoc process. However, as a framework for change Kanban and Scrum can be compared as alternatives.
It is in this area, as frameworks for change, that I feel I can add to the existing literature as Kniberg & Skarin did not address this aspect.
Change Catalyst
Kanban uses the WIP limit as its control mechanism to provoke conversations about change. Failure to respect the WIP limits and discuss problems will lead to stagnation and a failure to improve. Improvement discussions are objective as the visualization, measurement, explicitness of policies and the models from Lean, Theory of Constraints and the teachings of W. Edwards Deming, allow a team to scientifically analyze their problems and propose solutions.
Scrum uses commitment as its control mechanism for provoking changes. Commitment exists at two levels: at the personal daily level - this is reinforced with the Scrum and the 3 questions “what did you do for us yesterday?” “what will you do for us today?” and “Is anything impeding you from meeting your commitment today?”; the second commitment is at the team level, the Sprint commitment, a promise to deliver something on a certain date. Failure to meet a commitment should lead to a discussion about the failure that should provoke a process improvement. While we could debate the effectiveness of this approach, let’s accept that it works.
So Kanban uses a WIP limit as a change agent and Scrum uses commitments. This is a fundamental difference in approach.
Evolution rather than Revolution
Ken Schwaber has talked about the “hard words of Scrum” such as Scrum, Scrummaster, Sprint, and so forth. Scrum is intended to be shock treatment for an organization. It often involves people taking on new job titles, new roles and responsibilities and it is generally introduced in managed fashion with training and a defined date to switch to the new approach. Introducing Scrum represents a revolution. It shakes up the social hierarchy of an organization and affects (both negatively and positively) the professional self-esteem and egos of team members. Not every project manager values being told they need to retrain and assume a new job title! For some organizations this will be the right approach - they need shock treatment to avoid disaster. For others, all it does is raise emotional resistance amongst the workforce and encourage passive aggressive behavior.
Kanban is designed as the antithesis of the Scrum approach to change. With Kanban you start with the process you have now. You “kanbanize” it by mapping the value-stream, visualizing it, and limiting work-in-progress to create a pull system. You leave existing roles, responsibilities, job titles and practices intact. The only changes are to the interface with upstream and downstream partners, such as business owners and systems operations. Any changes made here are specifically chosen to avoid shaking up the social hierarchy or invoke an emotionally defensive response from affected people.
Kanban provokes evolutionary change. Initially this means process optimization - Kaizen - but gradually as the organization matures in capability it leads to larger managed changes - Kaikaku. It has been observed that progressive kaizen events lead to improved organizational maturity and capability enabling more dramatic kaikaku level changes.
So Scrum is introduced in a diametrically opposed fashion to Kanban. Kanban is softly softly and Scrum is hard shock treatment!
Conformance to Process
While Scrum is advertised as a starting point and a framework that will provoke change, there has been a growing market in practice-based conformance and assessments. The best known of these, endorsed by Jeff Sutherland is referred to as the Nokia Test. These tests determine whether you team is following Scrum. If not then the team is said to be “Scrum-But” and Ken Schwaber has taken to calling practitioners of non-conformant Scrum by the insidious term “Scrum-Butt"s. The effect of these conformance tests is to discourage innovation and deviation from textbook definitions. The net effect is confusion as on the one hand the leadership of the community tells practitioners that Scrum is about catalyzing emergent behavior in their organizations, while the same leadership prescribes a test that is designed to punish those who deviate from a standard definition.
Kanban is designed as an approach that will customize and evolve an existing process regardless of what that existing process is at the start. It is therefore impossible to define a conformance test for Kanban. Kanban uses 5 seed properties to catalyze the emergent behavior of process evolution. These 5 properties are: Visualize the Workflow; Limit Work-in-Progress; Measure Flow; Make Process Policies Explicit; Use Models to Evaluate Improvement Opportunities. These represent the 5 practices that must be present for the Kanban approach to change to work. The team’s process for software development and project management will always be unique and over time will be tailored and optimized to the value-stream, risk profile, skills and capabilities of the team, customer demand, bottlenecks and sources of variability that affect the team. There can be no test for conformance. Any measurement that might apply should measure whether a better economic and sociological outcome was affected by the introduction of the Kanban approach.
Containers versus Whole System
There are a number of other properties that emerge with teams using Kanban that differ from practices of teams doing Scrum. These emergent differences are mostly a side-effect of not pursuing the “Container” approach of Scrum. Scrum uses a container known as a Sprint that time-boxes a batch of development work and discourages interference from outside. Ideally there should be no interference. Scrum seeks, like good software architecture, to minimize the interfaces from the container, to achieve a loose coupling. The desired effect is to make the activity within the container - the Sprint development - as predictable as possible, in order to meet the Sprint Commitment.
Kanban does not introduce such a container, instead it encourages a whole system view. A number of mechanisms simplify the coordination of elements in the whole system. For example, the combination of visualization and a WIP limited pull system enable a very simple interface with business owners. As a result most organizations adopting Kanban do not need the single Product Owner concept of Scrum and can easily cope with multiple competing business owners attending queue replenishment meetings.
Kanban daily standup meetings have been shown to be effective with up to 50 or more people. The reason for this is that the team are implicitly trusted to be doing the work that is shown in the visualization of the workflow. There is no need to use the standup to reinforce personal commitment and hence the standup can focus on the work and not the people. Teams will iterate over the work tickets rather than through the team members. The three questions are obviated. More mature Kanban teams reduce discussion only to work that is impeded or defective, focusing only on exceptions rather than work that is proceeding normally.
Organizations using Kanban have also been observed to merge smaller teams to take advantage of the reduced coordination costs and better utilize their labor pool. It’s become common to see teams of 20 to 30 and sometimes up to 50 being created often from multiple (former) Scrum teams, or from a mix of Scrum and non-agile teams. The workflow visualization often involves multiple rows (or swimlanes) to represent different streams of development. Some team members may be assigned to a swimlane as permanent team members, accountable and responsible for work in that lane, while others are allowed to float across lanes to provide staff augmentation or specialist skills. The result is more effective and efficient use of the available people, resulting in more throughput and shorter lead times.
Closing Thoughts
I believe that we are only beginning to understand the differences between Scrum and Kanban. I believe that as more emergent properties of Kanban organizations are observed as recurring patterns in the field, we will grow in our understanding. Kanban differs from Scrum. Where we are still learning is how introduction of Kanban to an organization using Scrum changes that organization, its culture and its approach. I believe that Kanban is compatible with the mechanics of Scrum. It is compatible with Scrum, the project management method. Adding WIP and visualization to Scrum will help improve Sprint Commitment effectiveness. However, it is also introducing the WIP limit as a mechanism to catalyze incremental changes. Scrum teams adopting this approach are said to be Scrumban teams. The WIP limit obviates the need for commitment to drive change, reduces any dysfunctional reliance on heroic effort, and improves overall systems thinking when considering potential improvements. Scrumban will replace the Scrum philosophy and framework with the Kanban approach. It may still look somewhat like Scrum at the practice level but at the cultural level it will be Kanban - softly softly evolution rather than shock treatment and revolution.
When considering whether Scrum or Kanban is right for you and your business consider the culture and maturity. If your organization has low maturity, limited capability at risk management, change management and decision making, and is riddled with specialization and defensiveness then Kanban is probably a better choice. If you have time to let the culture and performance evolve and improve over months and years then Kanban is the right choice. If on the other hand, your organization is highly mature and capable of assessing risk, evaluating process alternatives, making good quality decisions, and managing high impact change gracefully then Scrum may be the right choice for you. If you are facing an extinction level event and you don’t have time to let evolution work its magic on your organizational performance then perhaps a Scrum revolution is worth the risk.