Scrum and Kanban

Henrik Kniberg and Mattias Skarin compare Scrum and Kanban in their book “Kanban and Scrum – Making the Most of Both”.

Scrum consists of
Small cross functional self-organizing teams
Time boxes for the Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective
Artifacts: Product Backlog, Sprint Backlog, Release Burndown and Spring Burndown.

Scrum requires small cross functional self-organizing teams. Each Scrum team is composed of a product owner, a ScrumMaster, and the team. The Product Owner maintains and prioritizes the product backlog in a way that maximizes value of the work performed by the team. The team works in short fixed length iterations and consists of developers with all the necessary skills to deliver the committed to features by the end of the iteration. The Sprint starts with a Sprint planning meeting to produce the Sprint backlog from high priority feature in the product backlog. This is followed with daily work on small concrete items from the Sprint backlog, and ends with a Sprint Review to demo the deliverables as well as a Sprint retrospective to review the process. Everyday the team also has a Daily Scrum meeting to ensure progress towards the Sprint goal and update the Sprint Burndown chart. A release planning meeting is held before the start of each release to estimate and prioritize features to be included in the next release. After each Sprint, the Release Burndown chart is update to show and track release progress. Throughout, the ScrumMaster ensures that the process is understood and followed and removes any impediments to the team’s progress.

Kanban is based on limits on Work in Progress. It uses a visual control mechanism (Kanban Board) to track work as it flows through the various stages of the value stream. The board tracks states like to-do, in development, in testing, completed, etc. Each state has a limit on the number of items that it can hold. Work is split into pieces and progresses through the workflow however no items can proceed unless there is enough capacity in the next state. Lead time or cycle time is constantly measured and optimized to make it as small and as predictable as possible. Kanban does not prescribe artifacts and team composition like Scrum does. Kanban leaves everything open. The only constraints are visualizing the workflow and limiting WIP.

Henrik summarizes the similarities and differences as follows:

	Scrum	Kanban
Delivering releasable software early and often	“potentially shippable” at end of each Sprint	Scheduled or on demand
Transparency to drive process improvement	Product Backlog, Sprint Backlog, retrospectives	Kanban Board
Pull Scheduling	Items are pulled from product backlog at beginning of each Sprint	Items pulled when a slot becomes available
Iterations	Timeboxed iteration prescribed for Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective	Timeboxed iterations optional. Process can be event driven instead of timeboxed. Each meeting can occur at different times.
Resets	Sprint Backlog/Scrum board is reset after each Sprint	Kanban board is persistent
Item Size	Items must be broken down to fit into 1 sprint	No sizing requirements
Estimation	Estimation prescribed	Estimation optional
Prioritization	Prescribes a prioritized backlog	Prioritization optional
Commitments	Team commits to specific work in an iteration	Commitment optional.
Process Improvement Metric	Based on Velocity	Based on Lead time
Artifacts	Product Backlog, Sprint Backlog, Release Burndown and Spring Burndown prescribed	Kanban Board
WIP Limits	Indirectly based on what can fit into a Sprint	Directly based on limits set for each stage in the workflow
Responding to change	Cannot add items to an ongoing iteration	Can add new items whenever there is capacity
Team composition	Cross-functional teams prescribed	Silos and specialist teams allowed
Ownership	Sprint backlog is owned by one specific team	A Kanban board may be shared by multiple teams
Roles	3 roles: Product Owner, Team, ScrumMaster	No roles prescribed

Henrik and Mattias recommend you not limit yourself to one tool. Mix and match as needed based on your organization's circumstances.

Kanban Adoption at SEP

Chris Shinkle gave a talk about Kanban adoption at SEP during the Agile 2009 conference. Chris described the Dreyfus Model of Skill Acquisition and showed how the team at SEP progressed from one stage to the other as they learned and applied Kanban.
Stage 1 – Novice: Little or no previous experience. It is about following context free rules. No discretionary judgment. Want to accomplish a goal, not learn. Team had clear understanding of project, clear priority of work items, and clearly see progress from the introduction of Kandan boards and standup meetings.

Stage 2 – Advanced Beginner: Still rules based, but start understanding rules within context and based on past experience. Team understood WIP (work in progress) limits, began to collaborate and identify bottlenecks and areas for improvement.

Stage 3 – Competent: People recognize patterns and principles. Rule sets become more rules of thumb. They start to establish guidelines and seek out and solve problems. They see actions in terms of long term plans and goals. The team felt a sense of ownership. They started pulling in alternate practices to optimize the process and solve specific problems. They began to discover and understand lean principles themselves. Things like cause and effect of flow, value, quality, quality, and waste.

Stage 4 – Proficient: People seek out and want to understand the big picture. They perceive a complete system instead of a set of individual parts. They can learn from the experience of others and take full advantage of reflection and feedback and correct previous poor task performance. The team starts to focus on throughput and reducing cycle time. They began to focus on optimizing the whole and reducing the cost of delay and WIP limits. Kaizen moments became more common place.

Stage 5 – Expert: They can look at each situation immediately and intuitively take appropriate action. They know what to focus on and can distinguish between important details and irrelevant ones. Chris’s teams haven’t reached this stage yet.

Chris believes that it is ok to talk about principles but teaching principles does not equate to acquiring a new skill. Kanban provides a framework where principles can be introduced. Then the process in and of itself is going to help encourage those behaviors and allow people to understand them at their own pace.

Next Chris shares the lessons learned:

1. Start by teaching practices, not principles

2. Don’t set WIP limits too low for a new team

3. Keep rules about moving tokens/cards simple

4. WIP is strongly correlated to product quality.

Finally, Chris concludes by stating that Kanban teams mature in a way consistent with the Dryfus model. Kanban is an effective tool for teaching lean principles and managing change in an organization. There multiple levels of maturity and at each level certain behavior guide your focus.

This presentation is available on InfoQ at  http://www.infoq.com/presentations/kanban-at-sep

A Kanban System for Software Engineering

At QCON London 2008, David Anderson gave a talk about Kanban. David starts by mentioning he had some failures in institutionalizing agile changes and failing to scale it to a significant size. He then had success with Kanban. Kanban system allows for focus on quality, reduces or limits work in progress, balances demand against throughput, prioritizes.

David then describes a case study at Microsoft where a team was at CMMI level 5 and producing high quality software however they had a huge backlog and items constantly delyed. David shows how implementing Kanban helped this team improve productivity by 200%.

Instead of having an agile transition plan and force a team to use a particular agile process, David now advocates starting from where you are now and create a culture that encourages people to improve, teach them lean principles, teach them about waste and bottlenecks, and then have the team figure out on how to get better.

David then covers another case study at Corbis and describes Kanban in more details. Kanban can work with specialist teams of analysts, developers, testers, QA, etc. However, it puts a limit on the amount of items that each team can process. There are no iterations in Kanban. It is more of a continues flow with a release every 2 weeks, but the release content is bound and published only 5 days prior. Items that take longer than 2 weeks are just not released. Prioritization meetings are held every week (inputs and outputs are not in sync in a cycle). Whenever there is an empty slot, an item from the backlog is added. Prioritization and competition for an empty slot eventually evolves into collaboration. No estimation is done on individual items, with the effort to estimate turned back into increased productivity in analysis, coding, testing, etc. The Kanban white board gives visibility into process issues (transaction cost of releases, transfer though stages, bottlenecks, ragged flow). Daily stand up helps eliminate impediments affecting productivity and lead time. Kanban also allows for scaling standup meetings. Large teams can go through tickets on the board and ask if anyone knows of something impeding the progress of the ticket.

David summarizes that the Kanban method enabled:

1. Culture Change: trust, empowerment, collaborative team working and focused on quality.

2. Policy Changes: No estimating, late binding release scope, late binding prioritization

3. Regular delivery cadence: Releases become routine.

4. Cross functional collaboration

5. Self regulating process robust to gaming and abuse

6. Continuous improvement: Increase throughput, high quality, process continually evolving, kanban limits empirically adjusted.

7. Little Management Overhead: Little to no involvement in day to day

This presentation is available on InfoQ at  http://www.infoq.com/presentations/kanban-for-software

Future Directions for Agile

At Agile 2008 David Anderson talks about agile principles, practices and the community. David covers multiple topics that reveal how CMMI, Kanban and Real Options Theory help in making organizations scale, lean, and of high maturity.

David mentions that trying to scale agile across an enterprise is forcing a change on the community. We are trying to expand agile to the entire IT department and even more to other areas like marketing and recruiting. We need a wider definition of agile that is not narrowly focused on software development. We have the manifesto and the principles, but it is 7 years old and in badly need of an update. David stresses that we should not underestimate the value of what the manifesto gave us, but it is not everything of what it means to be agile. David controversially states that the agile manifesto is superstitiously declared.

Next David clears up the ideas behind the manifesto and how can we capture them as a model in 3 underlying paradigms

1. High trust, high social capital, highly collaborative culture

David describes the different cultures between the traditional and agile communities. The traditional community was rooted in government and developed a body of knowledge from defense. The high cost of failure (money, lives, politics) makes people conservatives, risk averse, and have low trust. On the other hand, the agile community was started by thought leaders from start-up companies building web sites. They were innovating daily, empowering people to release new functionality with an assumed zero cost of failure. They realized that in order to innovate at a fast pace, there was no time to write requirement and negotiate contracts. It was better to let people work and adopt a failure tolerant attitude. This was a highly collaborative approach with a high trust liberal culture. This led to the 3rd value of the agile manifesto, customer collaboration (high trust) over contract negotiation (low trust). Self organization or empowering, delegating and tolerating failure through adoption of high trust culture is better than contract and audits in low trust culture.

2. Perfect is the enemy of good enough.

David mentions that CMMI taught us that project success came from organizational maturity. Level 1 is chaos, Level 2 is repeatable and Level 3 is a defined process. At this level we should be able to deliver successfully every time. So the assumption was that we need to pursue perfection and eliminate ambiguity and uncertainty. We need accurate plans, analysis, estimates, and diagramming. By the time we are done, they are already out of date. This led to the agile manifesto value of working software over comprehensive documentation.