Here is a video primer of the Schneider Culture Model and how Agile, Software Craftsmanship and Kanban fit in. It is recorded in HD so you may want to use full screen and 720p resolution to see all the slides.
For more information, please see Agile Culture Series Reading Guide.
(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 rigorous 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 argument 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 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 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.
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.
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.
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.
I am a visual thinker so I need a picture to put it all together:
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
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.
Many thanks to Jason Yip for helping me refine my thoughts and to Siraj Sirajuddin for getting me to attend LSSC10.
The picture I am painting may be missing something. Please share comments or get in touch with me directly to build a better model.
Mary Poppendieck gave her usual well-researched and convincing tour-de-force presentation at LSSC10 on several approaches to organizational change with a talk titled “What’s wrong with targets?”
The purpose of the whole talk is to trash Management by Objectives. See my related blog noting the damaging effects: SMART goals may not be that smart. As an alternative, Mary shares 4 effective models for organizational change.
I have heard a lot recently about the book Switch: How to Change Things When Change Is Hard by Chip Heath and Dan Heath. It uses the metaphor of the Rider and the Elephant. I like it a lot since it lines up well with my NLP tools and understanding of the unconscious mind. Anyway the change model is very clear:
Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother is a second approach for driving change. Check out the above description in the mind map. It reminds me of the A3 technique that I have been using for the last year with great success. I’ll blog on my experiments later.
Strategy and Deming’s systems analysis + PDCA + People were the two final models to round out organizational change approaches that involve people rather than measure them. Caveat: SMART is OK for projects; not people.
Sadly, I did not do as good a job capturing the the LSSC10 keynote sessions as I would have liked, but maybe I captured something you missed…
Don Reinertsen really turned me off at the start of his session (The Easy Road to FLOW Goes through a Town named LEAN) which started with what felt like Kanban bashing 101. Many of his comments seemed aimed at a literal implementation of a production-like Kanban system in software – something I have not seen in practice. Despite this misdirection, there were some very strong points that I would like to highlight. See video/slides on InfoQ.
Elimination of Variability is Toxic. Great Product Development requires creativity, taking risks and encouraging failure. No errors means no learning. This reminds me of Jared Spool’s Keynote on building great products and aligns with efforts such as Enough Kanban! Use XP for Single-piece flow.
Don also introduced the Internet (TCP/IP stack) as a very different model for work execution. Again, I was a little disappointed since a lot of teams are already implementing similar elements. e.g. Different quality of service through urgent tracks in Kanban boards. A number of people said the talk was a quick synopsis of his new book: The Principles of Product Development Flow: Second Generation Lean Product Development and contains ideas that will shape lean software for the next five years. These are smart people so I am going to have to get the book.
The second keynote was by Bob Charette. I love the quote he shared with us about assumptions and risk:
“It’s not what you know that can hurt you; it’s what you know that ain’t so” – Will Rogers
I am reminded of the damage assumptions can bring every time I train people with my Scrum-friendly version of the XPGame. Bob points out that assumptions are risks we have accepted.
Profit = Exchange of Risk. There are three types of risk:
We need to choose between these to maximize profit
Check out blog post: Above All, Stay Open to New Ideas, Humble to the Current Limits of Our Knowledge, and Be Ready to Innovate, Absorbing Ideas from Other Bodies of Knowledge
Siraj Sirajuddin shared a deeply insightful reflection on the nature of Agile/Lean coaching. Lot’s of insights for me.
Below, I have a few notes that just scratch the surface.
A big take-away for me is that every day and every meeting I need to:
Another concept is Clean State Fridays where everyone goes home without emotional baggage so they can start fresh on the following Monday.
He also reminded me that we play a dance with courage and grace to achieve great outcomes.
Strongly suggest you check out the full presentation or find a way to see him in person.
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 skill sets 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.
AGILE LEADERSHIP & TRANSFORMATION
ONLINE TRAINING (ALT)
RETHINK YOUR APPROACH TO ORGANIZATIONAL CHANGE
