Alternate Title: A model for understanding Scrum and Kanban

(Cool diagram below – skip down if you are in a rush Or check out the 3 minute video explaining why Scrum and Kanban are complementary.

As I flew home after LSSC10, I wondered how Kanban-style software development would shape my world in the years to come. I self-identify as an Agile/Lean Coach and wondered what the road ahead looks like for me.

Someone at the conference commented that Kanban was going to dominate discourse in our community. Some people in the Kanban community say it is more widely applicable and is a more rigourous approach. Another commented that software processes historically have a 7 year run and so it is time for the age of Scrum to wane. The arguement goes that even if Kanban isn’t better, the community needs a new buzz to keep things going. All this made me wonder.

Is this true? If it is true, what does this mean for me? How can I reconcile this with what I know works? Before we delve deep, I need to share where I am coming from.

I use Agile

I have used Scrum for many years as a starting point for Agile transitions. It is compact, creates visibility, and builds a team culture. I also use XP practices.

I use Lean/Kanban

I have been using Lean concepts for many years and very heavily in the last year. I have made extensive use of Kanban-style Scrumboards as well as pure Kanban boards for business and support groups. I have had great success with other tools as well: root cause analysis, the A3 technique, and value stream mapping. This winter, I implemented Kanban with a 18 person software group and shifted behaviour with a cumulative flow diagram.

For me, Agile includes Kanban

When I read the Agile Manifesto and principles, I don’t see anything that excludes Kanban. All the XP technical practices still apply – perhaps even more so. Scrum notions of Product Owner, Product Backlog, and Retrospectives still hold value. Iterations may be gone, but they have left a trail of useful concepts of tools that the Kanban community enjoys. Maybe 80% is the same. Why am I making this point? Some proponents on Lean and Kanban highlight the differences rather than relationships: “Kanban is new!” “We are post-Agile” – as if that were cool. Our community is better served by focussing on the positive in every approach.

What I learned at LSSC10 that shifted my thinking.

At LSSC10, I started noticing contexts – what environments and circumstances encourage Kanban-style Agile.

Support Kanban What blew me away was a keynote case study on Kanban turned out to be about a couple of support groups who figured out that Scrum is not a good fit when there are lots of interrupts and emergencies. Ah, um, … not really news. This is the canonical case for Kanban.

Naked Planning or using XP for single-piece flow is about creativity and cross-functional teams swarming work (MMFs). The context here appears to be a team with a lot of focus working on innovations. This is much more similar to Scrum/traditional Agile rather than Kanban.

(Vanilla) Kanban Mike Fitterman and Rick Simmons of Constant Contact told the story of how Scrum wasn’t working out. Two development teams shared QA and product people and found there was too much planning and communication overhead. (Ooops, sounds like ScrumBut.) Anyway, the context in which they applied Kanban was with one with specialists and group that was too large to be a team.

Vale Kanban Alisson Vale described an environment with small work packages that come from a variety of demand channels. (See also video). It very much sounded like system evolution rather than discontinuous innovation. Interestingly, his model does not follow work decomposition by role but rather allows flexible routing and story swarming much like XP.

Production Line Kanban and (Vanilla) Scrum Most insightful of all for me to outline contexts was Clinton Keith’s session on video game development (go read it). He used a timebox for creative work both with takt-time in production-line style Kanban and with Scrum during design and problem solving phases. So, in this situation, they see Scrum for exploration and Kanban for cranking stuff out.

Scrum and Kanban fit different contexts

• Kanban can handle a lot of interrupts
• Kanban supports specialized roles with divergent skill sets
• Kanban excels at repeatable work such as a production line
• Kanban works fine for groups larger than 7+/-2 since communication and planning overhead is lower

• Scrum excels at projects requiring deep collaboration and innovation
• Scrum works best with small cross-functional teams (7+/-2)
• Scrum is great for providing shared goals and work context
• Scrum encourages generalists

For a more comprehensive list of similarities and differences see Kanban and Scrum – making the most of both. See also Jason Yip’s recent observations.

A model for thinking about Scrum and Kanban

I am a visual thinker so I need a picture to put it all together:

• The vertical axis differentiates environments with a strong focus from those with many interrupts and divergent needs.
• The horizontal axis indicates the spectrum from defined, repeatable work to exploratory and innovative work that benefits from swarming.

Every process has a sweet spot

I have indicated where I see various process styles play best. (For example, Scrum is good when there is focus and exploration.) The dashed lines suggest  that these are not hard boundaries. The regions and shapes are more illustrative than literal.

In this model, Kanban is at centre stage. I have repeatedly witnessed first hand that Kanban is very easy to implement and provides great benefits.

I also have seen the value in creating small, focussed teams using Scrum. For sure it is harder and yet very rewarding. On the downside: it doesn’t fit all contexts.

In truth, I am not 100% satisfied with the fidelity of this model, however, it helps me understand how to approach work with my clients

We need to know both Scrum/XP and Kanban

If all you have is a hammer, everything looks like a nail.

What tools do you have in your belt?

Henrik Kniberg gives the metaphor of comparing a knife with a fork. Which one is better depends on the situation. We need need to know both Scrum and Kanban. XP, too, but that goes without saying.

As an Agile coach I need to understand a client’s situation to know whether to start with Kanban or Scrum or both. Miyamoto Musashi – a famous Japanese Samurai spoke regarding choice of tools – said “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough.”

Let’s build community

For my Scrum and XP friends, Kanban is here to stay and it is going to continue to grow; let’s embrace it and help mature it.

For my Kanban friends, let’s build bridges and create a strong inclusive community.

Hungry for More?

• Kanban and Scrum – making the most of both by Henrik Kniberg and Mattias Skarin
• Kanban by David J Anderson (Just released)
• Scrumban – Essays on Kanban Systems for Lean Software Development by Corey Ladas

Thanks

Many thanks to Jason Yip for helping me refine my thoughts and to Siraj Sirajuddin for getting me to attend LSSC10.

What do you think?

The picture I am painting may be missing something. Please share comments or get in touch with me directly to build a better model.

Alternate title: Most Scrum teams need a Kanban board

I am a big fan of Scrum, however, the notion that there are no interruptions during a sprint is simply not realistic in many environments – especially teams adopting Scrum.

Let’s dream of perfection

A key concept from Lean is to dream of perfection. In this case, perfection is “no interruptions”. This is good as a goal but not as a starting point.

Deliver Value

Let’s face it, there is a lot of business value in keeping a production environment up and running. Almost universally, this is more important than getting that new feature out. Unfortunately, this value is usually a form of waste since there may have been things that we could have done to avoid production issues in the first place. It even has a name: failure demand. When we dream of perfection, we dream of zero production issues.

Oops. We live in a world where there are external events. Yep. It’s true. Even Scrum teams. Maybe it’s more useful to drop a story or shallow out some functionality when some important external interrupt happens rather than abort the entire Sprint.

Ken Schwaber told the story of getting kicked out of a client close to home for attempting to veto the company picnic in favour of focus on the Sprint commitment. I keep telling the teams that they are part of a bigger picture and they need to be in tune with that.

I follow the rule of letting Product Owners swap out unstarted stories for new ones if the team agrees. This comes from XP. Darn, broke another Scrum rule in order to maximize business value.

A separate support team is an anti-pattern

I keep getting asked – hey, can’t we have a separate support team?  Then there won’t be any interruptions. NO! Funny thing is that most technical folks don’t want to be on the support team. But the main reason is that it is very useful to have people developing software fix their own bugs and appreciate what it takes to get something working in production. Otherwise defect rates will climb steadily and that’s the wrong direction to go. We want zero defects, not more.

Most Scrum teams need a Kanban board

For as long as I can remember most teams I have worked with have had a support board where we track the actual hours spent on support. Why actual hours? This gives us history and the ability to predict support workload – very handy information during a Sprint Planning Meeting.

More recently I have used a Kanban board for managing support issues.  See sample photo below.

So now, my thinking is that most new Scrum teams probably need a Support Kanban. How about at your company?

Clinton Keith gave an insightful session around designing and configuration a Kanban system for leveled video game production.

Clinton described Scrum and Kanban coexisting peacefully. They used cross-functional Scrum teams to drive collaborative creative work at the outset of the project where team members would swarm stories. Aside from creating the game concept and playability, one of the outputs was to design and implement a Kanban system for producing game levels.

Game level construction requires different highly-specialized skillsets cannot help each other out – the audio engineer doesn’t know anything about graphic design. So Kanban is perfect. A system with fixed takt time was constructed and staffed appropriately to have a steady creation of game levels. Even the levels were broken up into zones to reduce batch size and improve flow.

Some team members continued to run 2 week sprints on solving challenging problems that came up during level construction and playability. For this environment it seems like Scrum and Kanban are both appropriate. This is a huge take-away for me – a better understanding of where Scrum makes sense and where Kanban makes sense.

Another interesting story was to Time Box Art to balance customer value with cost/time when developing artwork (see graph below). Artwork can go on very a very long time and it is difficult to define done. One solution to this is to create a timebox to focus work at the point of diminishing returns. Another benefit is that a timebox can drive creative energy. The example given was that for a high-speed car chase through Paris, you don’t need high-resolution buildings.

If you are interested in learning more, his book Agile Video Game Production is coming out May 2010. Video and slides of the session is on InfoQ.

Part of my standard training for Product Owners is to help them understand how they relate to everyone else in an Agile/Scrum world. Hence the drawing below.

Project Community Diagram

The Product Owner is not part of the team since their role is to ask for more to keep productive tension in the system. I like the way Ron Jeffries narrates about the Product Owner Role without ever using the term. This is a good story. So is the follow-up one.

I like the XP notion of the customer team to reflect the group representing the customers interests. (If anyone can suggest a good link/definition, I’ll add it.)

Why is the ScrumMaster outside? Their primary role is to act outside of the system to help it function and grow. Why is the ScrumMaster cheering on top? Ooops. That’s a bug. If I had time to re-draw, I’d put them underneath holding up the whole system as a servant leader.

So what do you do, if you don’t like the way I have parsed the world? Please help me understand your perspective – draw a picture to show me the world through your eyes.

There was a really good session at the Scrum Gathering’s Open Space on some of the challenges around the CST application process.

What I want to share here is some general thoughts on what is required to be a Certified Scrum Trainer that I noted during the open space session. This is only an excerpt on how to succeed – the full session notes are here.

(Part 4 of 5 blogs on the Scrum Gathering in Orlando)

Caveat: There is a Scrum Alliance Improvement Committee working out the new process so this is an informal look at some considerations.

See mindmap below.

It is important to get connected so that people know who you are. If you are considering co-training, find people you like. (N.B. There was some discussion of dropping Co-training requirements so you’ll have to stay tuned on this.)

What you teach when you are CST is your business, however, the evaluation process is based on you wearing your scrum hat. Not your Agile hat. Not your XP hat. Not your PMI hat. Does this mean I need to show a flock of self-organizing geese? Is it OK to share the Agile manifesto? I still don’t know the answer to these questions.

As a CST you will need to develop a curriculum with learning objectives, exercises, etc. There is no official training material that you can use as a baseline – every CST is expected to author training material.

It is important that you contribute to the Scrum Community. This can take the form of organizing a local user group, a conference. Public speaking and publishing articles and blogs is relevant as well.

The big thing I got out of this session is that no one is going to hand you the CST designation because you know Scrum and have run training sessions. Becoming a CST requires excellence and hard work.

You may also want to check out Tobias’s blog posts: So you want to be a CST?, Becoming a CST and Scrum gathering day zero for an informal perspective.

See also my post on becoming a CSC.

I started filling out my CSC (Certified Scrum Coach) application almost a year ago and then I stopped due to fear, uncertainty, and doubt. I had been using Scrum for quite a while and successfully transitioned a number of teams, but didn’t understand the process and have any context around it to understand how to be successful and even if I should bother.

(Part 4 of 5 blogs on the Scrum Gathering in Orlando)

I signed up for help in the Dialog Room’s Scrum Clinic (thanks Gerry Kirk and Michael de la Maza) the Scrum Gathering.  Roger Brown was kind enough to sit outside by the pool with me and fill in the missing meta-data around the CSC application process. The mind-map below is my effort to capture his perspective on this topic.

The big take aways for me were:

1. Now that I know the process, criteria, expectations and outcomes, I feel comfortable proceeding.
2. A submission needs to be business professional and may take 10-30+ hours to prepare.
3. Three reviewers will score each section to arrive at an overall score (like an exam). No minimum for any section.
4. Agile work is OK, but Scrum is preferred and will score higher.
5. I need to publish an article on the Scrum Alliance website.

Thanks also to Bob Hartman for reviewing and offering his time to help.

Caveat: this is not official Scrum Alliance policy – this is just my understanding of a discussion on this topic. Please see official CSC page here.

At the Scrum Gathering Open Space, there was a great session on this with even more details on the CSC program; please check it out.

Yesterday, Gerry Kirk and I kicked off a 4 day Agile Assessment with a presentation aimed at taking some of the uncertainty out of Agile and providing context for the transition/assessment.  See slides below.

The values and agile project life cycle slides were not show; instead, Gerry did a live diagram construction (see photo below). This approach worked well and we got lot’s of great questions.

One of the questions was about Agile contracting.  There is a good presentation I commented on in a recent post.

I was really excited to see the presentations from the Munich Scrum Gathering posted on the ScrumAlliance site since I was not able to attend due to a date conflict with Agile Tour Toronto. It took some time to go through all of them so I thought I would post some of the ones I found interesting here to encourage you to check them out and maybe some others. A big thank-you to the Scrum Alliance and authors for posting them.

Ideas from Other Fields

Making Change Happen – Peter Stevens

Peter Stevens has a visually pleasing presentation – Making Change Happen – that summarizes organizational adoption challenges and includes key ideas from one of my favourite books – Fearless Change. The diagram at the left illustrates that there are often factions in an organization pulling in different directions with different agendas – not just your favourite (Scrum or Agile). Check this out if you are involved in organizational change.

Social Objects in Software Development – Dave Harvey

Scrum talks about self-organizing teams. How do you get there? One idea is that we need to think about social networks. These form around social objects, so this is a good place to start. Social objects reinforce our identity and sustain our tribal identity. Consider the photo showing other dimensions of people’s lives. Not only can networks form around this, but it also primes our behaviour to think about others as … people. The presentation is done in zen style and I would totally love to hear Dave in person.

Self-Organizing & Subtle Control: Friends or Enemies? – Mike Cohn

Mike talked about self-organization not happening in a vacuum. It is management’s responsibility to guide the evolution of behaviours (rather than specify what how everyone needs work). He then went on to talk about Containers, Differences and Exchanges as a way of making indirect changes to a team. There is also a discussion of Philip Anderson’s 7 levers for influencing team evolution. Worth checking out if you are interested in coaching teams.

Stories from Scrum in Practice

Agile at Telefonica R&D Gemma_Hornos & Monica Izquierd

Although the presentation is about large scale enterprise adoption of Scrum, there are lots of interesting bits of information that apply in general. One example is image is about styles of growth of Scrum within an organization – I really like the viral/mosquito! Lot’s of other great visuals as well.

 
 

Practical Roadmap to Great Scrum – Jeff Sutherland

Jeff shares some of his key understandings of doing Scrum well. Want to double productivity? –> Focus on DONE. Want to double again? –> Focus on READY. Self-organization is identified as the 3rd way to double performance. The presentation also talks about large scale adoption and CMMI. Lot’s of good bits of info packed in here.

 
 
 

10 Contract Forms For Your Next Agile Project – Peter Stevens

Peter has a great analysis of the advantages and disadvantages of different types of contracts from both the vendor and the supplier perspectives. Phased development (see photo at left) is one that balances the interests of bother parties and encourages cooperative behaviours. If you need to set up a contract, check out this presentation.

 
 

Kicking Scrumbut – Rowan Bunning

Rowan takes a fun and informative look at some common failure modes that organization exhibit when adopting partial Scrum (AKA Scrumbut). Of course all the failure modes are matched with advice on what to do to resolve the problem. Even if you are an experienced coach or Scrum practitioner, you will be sure enjoy and learn from a different perspective.

This is a list of some resources that are useful for getting started or growing your understanding of Agile.

The permanent page for this content on my website is here (so this is better place to link to since it will be updated).

Getting Started

Short articles for printing out and reading while you are on the train/subway.

• Agile Manifesto – Web page
• Agile Manifesto Principles – Web page
• Article on the history of Iterative developement
• Connections between Lean and Agile
• Short Scrum Guide – 13 page article/guide
• Scrum on a page – This you can put on a wall near you.

Intro to Scrum/Agile

• A Gentle Introduction to Agile – Presentation
• Agile Executive Briefing – Presentation
• Scrum in 10 minutes – Video (10 min)
• A Day in the Life of a Scrum Team – Video (6 min)
• Scrum Overview by Ken Schwaber – Video (60 min)
• Overview Powerpoint by Mike Cohn

Other Stuff you need to know to get your project started

• Getting started with User Stories – Book Excerpt
• Agile Estimation and Planning by Mike Cohn – Video (90 min)

Next Steps

• Check out some of the other resources below.
• Start reading some of the books.
• You have started a journey of learning – be patient and enjoy the trip.

Additional Learning Resources

• Scrum
  • Scrum Overview by Ken Schwaber – Website
  • Scrum Overview by Mike Cohn – Website
• XP
  • eXtreme Programming on C2 Wiki.
• User Stories
  • An Introduction to User Stories – Presentation
• Agile Estimation and Planning
  • Agile Estimation and Planning – Presentation
• Lean
  • Demo showing impact of bottlenecks
  • Lean for Business – Website
• Fun Stuff
  • Punchy video about how Agile can improve on Waterfall
• Agile Team Room
  • Agile Team Room – Photos
  • How does radical collocation help a team succeed?
• Pairing – team collaboration on tasks
  • Benefits of Pair Programming – C2 Wiki
  • Benefits Research Paper – Cockburn & Williams
  • How Pair Programming works - General concepts behind pairing and pair programming] (used in training)
  • Promiscuous Pairing - Some ideas on how rapid pairing can cultivate creativity. Also, How-to Article
• Agile Documentation Practices – Web Article
• Agile Testing – Video (60 min)
• Automated Testing
  • Automated Acceptance Testing – Presentation
• How Agile are you? (Agile Adoption)
  • Nokia Test – basic Agile test
  • Uncle Bob’s more extensive test
• Crystal Clear – low ceremony Agile process
  • 7 Properties of Crystal Clear – Article
  • 7 Properties Mind Map

Books to Read

Stage 1: Getting the basics in place

• Agile and Iterative Development: A Manager’s Guide
• Scrum I: Agile Software Development With Scrum – Basic Instructions
• Scrum II: Agile Project Management With Scrum – Stories about Scrum Usage
• User Stories Applied: For Agile Software Development
• Scrum and XP from the Trenches
• Agile Estimating and Planning

Deepening the practice

• Implementing Lean Software Development: From Concept to Cash
• Agile Software Development: The Cooperative Game
• The Software Project Manager’s Bridge to Agility
• Scrum III: Enterprise Scrum

eXtremeProgramming

• Extreme Programming Explained: Embrace Change
• Extreme Programming Installed
• Art of Agile Development

Technical Practices

• Domain-Driven Design: Tackling Complexity in the Heart of Software
• Refactoring: Improving the Design of Existing Code
• Agile Testing: A Practical Guide for Testers and Agile Teams

Lean

• Lean Software Development: An Agile Toolkit
• The Goal: A Process of Ongoing Improvement
• Critical Chain
• Lean Thinking: Banish Waste and Create Wealth in Your Corporation

Other good ones

• Crystal Clear: A Human-Powered Methodology for Small Teams
• Managing Agile Projects
• Fearless Change: Patterns for Introducing New Ideas

Games & Simulations

• XPGame – learn how Agile really works
• Leadership Game - learn different leadership styles and how you relate to them
• Bottleneck Game – learn how to improve your processes to eliminate bottlenecks
• Business Value Game – learn strategies and challenges with prioritizing work (product backlog)

Below are the slides from my first presentation at AgileTourToronto. It is based on ideas from Alistair Cockburn (among others) and has been a work-in-progress since I started sharing Agile ideas in 2002.

Presentation Overview

There are a lot of choices and alternatives for getting started with Agile. It can be confusing. This talk will give you a brief guided tour of Agile methodologies so that you have some understanding of how they are similar and how they differ. We’ll cover some of the history of iterative development and waterfall as well as the Agile Manifesto to provide context. At the end of this, you will have an understanding of key principles and the Agile landscape.

Slides on Slideshare

A Gentle Introduction To Agile