When I started coaching Agile methodologies, I didn’t know how much I didn’t know.
I had come from Thoughtworks, a company whose tools and processes are mostly driven by Extreme Programming, aka XP. In that respect, most of what I learnt and coached was very similar to Scrum, albeit with different words. We called them iterations instead of sprints, and had stand-ups instead of daily scrums. We had planning meetings, but we didn’t make commitments – just estimates. We had collaborative code ownership and a focus on delivery instead of a cross-functional team, which meant that we ended up with flexible and blurred roles anyway. We had the same problems – getting people co-located, helping business stakeholders become more comfortable with the risk and uncertainty of software delivery, and changing the culture and the infrastructure of the organisations in which we worked. We also had a number of technical practices like unit testing and continuous delivery that aren’t really prescribed by either Scrum or Kanban, but which both put forward as a Really Good Idea.
In the last few years, I’ve been privileged to be part of the Kanban community. I don’t consider myself part of the Scrum community as such, but I’m part of the larger Agile movement and strongly aligned through my background in XP.
In this post, I’d like to cover some of the differences I’ve seen between Scrum and Kanban, and add in some insights from the Cognitive Edge training I’ve done using Cynefin and complexity thinking. This isn’t going to be a full description or comparison, but it should hopefully provide some food for thought, and allow people to see some of the different tools available from both approaches.
Disclaimer: I haven’t explained every term I’ve used, or every practice I’m referencing. I’m assuming familiarity. If you don’t have it, you can to run a search on anything I haven’t linked. I’m also using the terms “Scrum” and “Kanban” as aliases for the community and / or leadership, and I haven’t made much distinction between Scrum.org and the Scrum Alliance. This is deliberate, and I welcome feedback.
Scrum and Kanban have more similarities than differences.
Both methodologies put people and their interactions at the heart. Both have a clear focus on value, fast delivery and the continuing growth of the team and its ability to achieve those valuable deliveries. Both contain mechanisms for feedback and improvement, allowing processes to change according to context. Scrum used to have a very prescriptive format – not dissimilar to XP – but this has been flexed in recent editions of the Scrum Guide, as alternatives to some of the practices have emerged. It’s not even beyond the realms of possibility that some of the alternatives have emerged from the Kanban movement!
Also recently, Scrum has started to evolve from being a set of processes to being a very loose framework in which processes can themselves evolve. Used this way, it joins Kanban as a meta-process, from which the real process emerges and continues to emerge.
IMO, both are infinitely better than that broken model called Waterfall, and both are better than having no process at all.
Scrum isn’t about the Scrum Meetings, and Kanban isn’t about the Kanban Signal.
Both methodologies are named after just one small aspect of their whole. In Scrum, the scrum meetings allow the team to share learning and information about how they’re doing and to make decisions about what to work on next. In Kanban, the kanban signal – showing that someone is free to help move a piece of work closer to delivery – provides a similar focus point. Scrum teams frequently use a card wall that’s similar to that of a Kanban team. Kanban teams frequently have daily meetings like Scrum. To an outside observer, the differences could seem so small as to be irrelevant.
Kanban measures lead and cycle time, Scrum measures velocity.
Both Kanban and Scrum have their origins in “Lean” thinking. We like to think of “Lean” as the set of principles behind the Toyota Production System – the process by which Toyota builds and churns out its cars – but both methodologies have an implicit recognition that software development holds more similarities with product development than a production line. In Toyota, kanban cards are used to help eliminate large amounts of spare parts and other inventory building up; providing a buffer which lets work flow through the system. Both Scrum and Kanban value this flow. Kanban suggests limits on the amount of work in progress, allowing constraints to be addressed. Scrum encourages collaboration, causing less work in progress. Scrum uses the proxy of velocity and estimation, which can help to prevent metrics around productivity becoming targets. Kanban uses lead and cycle time, tying its measurements to valuable targets that are hard to game.
Scrum starts with the right context; Kanban improves the existing context.
I once asked a Scrum practitioner, “What do you do if you don’t have a cross-functional team and you’re not co-located?” He told me that that’s the hardest bit of Scrum – starting from the right context. I realised that these difficulties, once overcome, also provide significant value. Just starting from the right context might be a good idea!
On the other hand, Kanban is neutral regarding context. Of course we think that being co-located is a good idea. Of course we’d love to have multi-skilled, flexible, collaborative professionals. If only this was as common in the industry as we’d like. Kanban’s focus on metrics and its measurements of lead and cycle time might make the impact of not having these apparent, so it’s a good place to start. (I used to think it was only suitable for highly skilled, disciplined, advanced teams, but experience and experimentation has taught me otherwise).
Kanban visualises what’s happening; Scrum visualises an ideal.
This is one of the biggest differences for me. The extent to which Kanban visualises reality is extreme enough that the board might not even have linear flow. Whatever the process policies are – whether helpful or otherwise – Kanban focuses on making them explicit, so that they can be addressed and improved. If the team happen to work with five different phases, this is reflected. If the team write technical stories, they go on the board.
In contrast, Scrum teams tend to set up a visualisation of an ideal process, helping teams to adopt that process. Done prescriptively, Scrum provides a “big bang” starting point. Because it consists of step-by-step practices, it’s easier for beginners to adopt. That could be Scrum’s blessing – but it’s also its curse.
Certification and early adoption.
Scrum has certification. Kanban doesn’t.
Yet.
In the early days of Scrum, there were few enough trainers and experienced Agilists that no matter who taught Scrum, it was done pragmatically. Early adopters tend to experiment, and those experiments led to a better understanding; to a focus on people and interaction, rather than process. Unfortunately the “Scrum Master” certificates are easy to get, compared to any other discipline that asserts a quality of mastery or independence. The training provides simple practices that are relatively easy for teams to adopt. Scrum is taught by a wider group of people, and the quality control over that teaching has become harder to maintain.
As a result, Scrum has been widely adopted and is considered pretty mainstream – the default Agile methodology – but the certificates associated with it provide a level of confidence that the training generally doesn’t support. I’ve met a couple of excellent Scrum trainers, but I’ve also seen “masters”, armed with their certificates, instituting mini-waterfall and silo’d teams as they replace those parts of Scrum that aren’t prescriptive, or that they don’t understand, or that they can’t achieve within a context that they can’t change.
Any examination or certification body suffers from a paradox: while the people who rely on those qualifications need them to be rigorous, the people teaching and taking those qualifications would much rather they were easy. The Scrum Alliance and Scrum.org between them have both helped to set up and reinforce the desirability of their certifications, and I can only imagine the difficulty that their leaders face in balancing the financial incentives involved against the good of the IT community and industry.
In contrast, Kanban is still in an early adopter phase. We’re still working out, as a community, what’s possible. Most Kanban practitioners and coaches are bright, experienced, willing to experiment, desiring of feedback and able to share and learn from each other in a relatively small community. Scrum no longer has that luxury. We don’t know what will happen if and when the Kanban community treads the same path, but we do have the advantage of being able to learn from what’s happened with Scrum.
You can also bet that the leaders are being watched carefully by the rest of the community to see how they meet this challenge. So far I think they’re doing an excellent job. So far there are no certificates available. So far.
Some thoughts spurred by Cynefin.
The Cynefin model of complexity thinking teaches us that in a complex environment – one in which cause and effect can only be understood in retrospect, and which includes most systems with people in, as far as I can tell – we should increase the opportunities and incentives for interaction, so that the practices best suited to the context can emerge.
Waterfall treated software development as complicated, using Cynefin’s domain definition; as though each project was a thing that could be taken apart into many pieces, analyzed, then put back together as a whole. Unfortunately the ability of human beings to make mistakes, combined with our inability to either effectively communicate our intent or see into the future, has meant that this was always doomed to fail. (Most successful Waterfall teams, who complain to me that I label it unfairly, have not practiced it in a pure form, and have included elements of iteration, feedback and common sense. When these are lacking, any methodology is doomed to failure, but Waterfall above all others doesn’t mandate or even leave much room for them.)
When we look at applying Scrum prescriptively to a Waterfall team, we’re looking at pushing forward increasing levels of interaction in a context in which interaction is easy – where teams are co-located, have all relevant skills, are willing to collaborate and can share learning. Scrum’s acts of estimation and breaking stories into tasks force team members to talk to each other. The act of commitment which Scrum recommends in planning meetings causes a team to discuss their concerns frankly. The cycle of feedback and retrospection allows the team to discuss whether they’re delivering value and how to do it more effectively.
But Waterfall is no longer the context from which we always come. Many Agile adoptions aren’t taken up by teams doing Waterfall; they’re taken by teams who have abandoned their process altogether, and are talking and sharing their learning in order to work out what to do next, while having no metrics against which they can improve or track their progress and risk.
The context in which Scrum starts is not often possible. We’re not always co-located – many start-ups and companies now allow developers to work from home, and the industry still seems to suffer from a delusion that offshore work is cheap to obtain. We may not have multi-skilled people – it takes some time to learn skills. In both the environments which are already more collaborative than Scrum, and the ones which are a long way from being able to do it successfully, Kanban can be useful.
I fear that this may include the majority of environments and the IT industry, and that’s why I choose to hold myself closer to the Kanban community than the Scrum one. IMO, Kanban works in a larger set of contexts than Scrum does, even though for a subset Scrum might achieve results faster.
They’re still more similar than they are different… and I still like XP too.
Liz Keogh, lunivore 
“In both the environments which are already more collaborative than Scrum, and the ones which are a long way from being able to do it successfully, Kanban can be useful”
I think this sums it up really well. Our team did Scrum for years (not co-located) but after it started to go a bit stale we’ve begun introducing the Kanban method and opened up the “rules” of Scrum for discussion. The change has certainly got the team fired up again. I really like Scrum, it spurred a huge change for us, but still find some of the “rules” as specified in the Scrum guide a bit rigid, for example it seems crazy to specify lengths of meetings. Once the team has been self organising for a while it seems unfair to put these contraints on them.
Two thoughts:
1. AFAIK the Waterfall model was never meant to be a process to be practiced; at least Wikipedia points to http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf as the origin, which clearly lists the waterfall model as an intermediate step in developing a model that might be more accurate.
2. Your perception of scrum appears to be different from mine in a curious aspect. To give some context, I’ve been a fairly early scrum adopter, but never bothered with becoming a scrum master. I’ve been part of badly led and well led scrum teams, and have led some myself – including distributed teams in which people were not particularly multi-skilled.
I’ve found it useful not to use labels like “scrum” at all, but applying the same principles or, as you put it, focused on the people and interactions at the heart of both scrum and kanban.
I find it interesting that you recognize this (and the rest of your post illustrates that further), yet make a conscious decision to associate yourself more with one than the other. Surely it’s all about a set of techniques, not what you call it?
Hi Jens,
If I think of them more as anchors or attractors than labels, then I am more attracted to Kanban than to Scrum. I’ve used different aspects of both, and have found that the techniques from Kanban – even used non-prescriptively, alongside more Scrum-like methods – are really great in getting teams up and running and owning change within their own processes. My experience of Scrum teams is that they seem to require coaching for longer. The “big bang” change is hard, and provides a great start, but the team can’t own it as effectively.
It’s not just about the set of techniques, it’s about who helps the team to do them. Kanban teams don’t really have an equivalent of a “Scrum Master”. Maybe that’s an important difference too.
I liked your post. You made a good sumary on comparing Scrum and Kanban, but I think some aditional comments are worth to be done.
– generalizations about methodologies are very hard to be done, and must be taken with carefull, because working methods decisions are local to the team/project; (there is no generic better one)
– methods are like tools, and the team must choose the best ones for the project at hand;
– so, the real agile team adopt the methodologie tools that best suits the needs/restrictions they face at the moment, and improvre it over the time; don´t be hooked on Scrum x Kanban;
– for the team, it realy doesn´t matter if the method comes to be scrum, kanban, scrumbam, xpcrumban, or anything else, as long as it works for them.
Kanban is a nice point to start. Completely agreed!
Hi Liz,
Thanks for sharing your ideas in this wonderful blog post. Reading it I couldn’t help but wonder if Kanban and Scrum are at the some level of abstraction. Pascal Dennis considers 3 levels of lean thinking:
1-Tools
5s, Visual Management, Kanban, TPM ect.
2- System
Tayota Production System, Alcoa Business System, ect
(Scrum, XP and Agile would fit in at this level)
3- Thinking
Mental models, PDCA, Go See, Respect of People.
Reading his book “The Remedy” one can’t help and feel Pascal Dennis is on to something. I found this split in tools, system and thinking very useful to get a better feel of what fits in where. In the model Kanban is a tool, where Scrum would be a system. This is the most significant difference between the two for me.
Hope this addition makes sense. I enjoyed you piece so please keep them coming.
Regards,
Jorrit
Hi Jorrit, as far as I can tell there are both tools and a system in Scrum and Kanban. Certainly I’ve heard David Anderson separate the Kanban Board and Kanban System before. There are also aspects of different mental models involved in both. I do find it useful to be aware of that split, yes, but I wouldn’t necessarily classify Scrum or Kanban as any one of those in particular – they’re just anchor terms for all the various tools, systems and ways of thinking involved in each, and for the community and leadership involved in their inception and growth. Definitely worth thinking about how the various aspects fit into the levels though. Thank you.
Liz, I think you’ll find that Scrum roots come from “The New Product Development Game” http://hbr.org/1986/01/the-new-new-product-development-game/ar/1 rather than lean like Kanban does.
Cheers
Nathan
Really? That’s interesting. I wrote this as a response to James Coplien’s article on Jeff Sutherland’s blog – “In this article, the term “Lean” will arise occasionally in quoted material that, unless explicitly mentioned otherwise, refers to the Toyota Way… Scrum is a framework for building product that is based on The Toyota Way.”
You’re right that there is a difference. Kanban is driven by more Lean principles than just those that Toyota use. But honestly, they’re still more the same than different.
I’ve just finished a master’s thesis with a mixed method study on mental model theory and organization pattern-theory. This organization is characterized by large teams (20+), ad-hoc processes, big bureaucratic customers and an appalling customer-technical coupling.
Five broad themes emerged in the analysis from their efforts to change:
– Power (desired a shift from power derived from customer-ties to internal information betweenness)
– Trust (the social networks were well-established, but roles and group affiliations frequently shifted and with trust grounded in the social network this had dramatic effects)
– Gathering awareness information (particular to task-expertise mapping, but also project status)
– Quality assurance during implementation (rigorous unit testing, formal code reviews, you name it and they want it)
– expertise coordination (found to be key in the perceived team effectiveness and viability, most of their efforts to change focused on this but failed with limited time/trust/power to implement them)
With awareness information a key element in taking control over processes the Kanban board can be most useful element in large teams. If the organization is unstructured and flexible as the one I’ve investigated, with such a strong desire to improve, taking control starts with understanding the flow of work.
I actually advised them to go through the Responsibility Assignment Matrix route as an exercise of how they would like to structure their processes.
At the same time, many of the patterns they attempt to introduce are those identified within Scrum as well (if I observe https://sites.google.com/a/scrumorgpatterns.com/www/scrumpatternssummary )
I don’t really understand why to put these two methodologies against one another and not focus on how they can enhance one another in different contexts. Discussing about the methodologies separately suggests a thorough knowledge and experience with both that few have…
Any agile methodology should provide the key relationships between patterns that only under rare circumstances are allowed to be broken. The weaker relationships should allow variation points to other methodologies.
An excellent article, however a few small points:
– Many Scrum Trainers myself included put alot of effort into emphasizing the importance of limited WIP even inside Scrum. My rule of thumb is that team should have no more stories in progress than half the number of team members. So a team of 7 can have up to 3 stories in progress, a team of 8 up to 4 stories. I find limiting WIP increases the likelihood of having completed stories in every sprint
– The Scrum Trainers I know contrary to your comment are not terribly worried about the money in the certification business and are busy trying to make the certification stronger. However creating a real recognized defensible certification takes a long time (think years). The delays come from the fact that the improvement process is volunteer work and dealing with outside agencies.
Finally Nathan is right Scrum is derived from the HBR paper. The way I tell my classes – its derived from the HBR paper and flavored by Lean.
As you say they have more in common than they have differences. In addition as both communities mature we will learn from each other. I liberally borrowed my thinking on Visualizing WIP from Dennis Stevens. He steals (in a good way) from me.
Cheers
Mark
Pingback: Project Wolverine » Blog Archive » Scrum vs Kanban (cont)
Nice article.
Minor typos:
“This is one of the biggest differences for me. The extend to which Kanban visualises”
extend -> extent
“If the team write technical stories, they go on the board.”
write -> writes
” Kanban works a larger set”
(maybe) works a -> works on a
Thanks, Brett! Fixed.
Hi Liz,
Nice post – “Scrum starts with the right context; Kanban improves the existing context.” is a lovely soundbite.
Thanks,
Royd.
Excellent post, Liz. And very timely in light of the Coplin’s blog on Sutherland’s site and the reaction that it is evoking from the Kanban community.
BTW – I hate the tension between the communities since I am an advocate for both and see value and use for both.
So, the one big takeaway for me from your blog is this concept of “context”. I guess it context determines which tool you will choose. If I were cranking up a new team or project – I am likely to use Scrum – since I can hope to implement as much of the ideal as possible.
If I wanted to move an existing team to Agility – I guess that Kanban may be the least disruptive and gradual way for them to move on their path to Agility. Especially, if all the elements that makes Scrum successful are not in place. Kanban, l think, gives the team and the supporting organization time and space to systematically put together all of those elements in place.
And once they are in place – I think that the team can decide whether to continue to use Kanban or to switch to Scrum. If it were up to me – I’d recommend that they move to Scrum. Why? Because, I have been privileged to be part of a truly hyper-productive Scrum team – which really cranked out stuff such that even the business couldn’t keep up with the pace at which they were delivering. 🙂 And that felt awesome!!!
Shyam, thank you for being one of the other people who would rather bring communities together than see them fight! I think there’s a lot we can (and have) learnt from each other. BDD and ATDDers get along mostly fine, and we trade and share techniques so much that only the langugage differentiates us. I’d like to see that with Scrum too.
Of course, Kanban would have flagged your business people up as a constraint… 😉
Liz and Shyam (and others) – I don’t think there really is a tension between the two communities. I think there is a tension between certain individuals but I don’t think we need to extend that to the communities as a whole. Most CST’s I know appreciate and like Kanban. Many Kanbaner’s I know teach and coach Scrum. The differences seem to be amplified by some (in both camps) for their own benefits.
In my case I find that Kanban and Scrum are both applicable in many cases. There are few that are Scrum only or Kanban only.
Cheers
Mark
At Agile 2008 in Toronto Mark Levison told me that by pursuing and evangelizing Kanban I was putting his livelihood (as a Scrum coach) at risk. Now he says he doesn’t care about money. I guess Scrum coaching has been paying well these past 3 years 😉
A very provocative and helpful post. It identifies what has started to worry me about agile: the focus on the ideal. Often the difference between “doing agile right” and “doing agile wrong” seems too abrupt. Interestingly, adopting agile often seems like a waterfall process, with too many culture/tool/process changes that all have to happen at once. A focus on “visualizing what’s happening and improving it” sounds more helpful. In terms of potential ossification, if it stays true to the spirit of continuous improvement, Kanban should always be improving/discarding what could otherwise become sacred cows.
Excellent article!
A minor point: “We had planning meetings, but we didn’t make commitments – just estimates.”
From the Scrum Guide 2011: “Commit is now forecast”
I.e., your planning meetings just the same as of now.
Excellent post, really interesting!
In my previous team we started Scrum 5 years ago. In the last year we introduced a Kanban board. We had reviews when we was ready with something and not always on the end of the sprints. Etc, etc…so what I want to say is that you can select some elements of Scrum and some elements of Kanban and use this mixture as your own best system. No need to choose onlye one or the other (or a third).
The most important things are to continuously improve and to measure something which can show the improvement. I think that is all. 😉
Nice blog Liz. A balanced view. Congrats…
Pingback: David J. Anderson and Associates - Kanban Weekly Roundup - Nov 22, 2011
Pingback: November 2011 Scrum vs Kanban Turf War | Nicholas Muldoon
Liz,
Great post.
The notion of visualizing an ideal vs what is happening is brilliant IMHO. It explains why I have gotten alot more traction with Kanban transfprmation than other attempts at agile adoption.
You now have a fan…
David – I’m not sure what you remember of that conversation. I recall that it happened at 3am over whiskey the details are in some doubt. I don’t believe for a second Kanban (or anything else) is a threat to helping organizations be successful. I use Scrum, Kanban, Open Agile and a good understanding of behavioural psychology to help teams today. In the future I will use what ever new tools I find. My goal is to help my customers deliver business value and delight their customers.
In addition I’m slightly surprised to hear that the details of private conversation are fodder for public comment.
Mark Levison
Pingback: Agile Manifesto – The First Amendment | Convivial Coding
@David Everyone’e livelihood should be put at risk from time to time. Keeps us lean and learning.
Pingback: Episode 18: Scrum vs Kanban War | The Agile Revolution