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.
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.