Scrum & Kanban – Different, But Compatible, Strokes For Different Folks

I find it curious when people criticise Scrum as if it is competing with Kanban. I don’t believe it is, and I don’t believe it is particularly worthwhile debating Scrum vs Kanban as two Agile methods because that’s not really the case. Kanban and Scrum have quite different purposes (although they do perhaps have similar intentions).

Put simply, the purpose of Kanban is to create a kaizen culture, one whose primary concern is that of learning, improvement and process evolution using “the scientific method”. Conversely, despite Scrum having lofty yet admirable aims of “changing the world of work”, the purpose of Scrum is to enable teams to develop products effectively. Scrum is generally a bottom-up, team-based approach and so, as the Kanban brigade rightly point out, it is not particularly (if at all) effective at instilling a kaizen culture (fortnightly team retrospectives, even done well, do not create a culture of continuous improvement in an organisation). It’s also not great as an enterprise solution to perceived effectiveness problems unless the organisation really understands the cultural implications of moving to Scrum across the board and has a collective mindset that can buy-in and adapt.

But here’s the rub. To me it’s not about whether an organisation should choose Scrum or Kanban – both are frameworks or methods for different contexts and different intended outcomes. Many companies have identified that they are crap at delivering software and want to get better at it. Rightly or wrongly, these companies are not seeking a kaizen culture. They simply want to deliver software better (by their terms), not improve their effectiveness overall. I am not saying this is a good thing but at least by choosing Scrum to (try and) improve their software delivery it might just get them thinking about the importance of learning and improvement to overall organisational effectiveness. I know from personal experience of coaching new Scrum teams (imposed or not) that they begin to get curious about Scrum and Agile, and then the curiosity spreads to Lean and Kanban. A good coach will introduce teams and their managers to Lean and Kanban concepts and techniques within Scrum (or evolving away from it as the team grows in confidence) as part of a drive for true self-management, measuring, learning and improvement. I have seen, and been part of, many Scrum-ban implementations. They may not have changed their companies for the better as a whole but they certainly helped those companies deliver software better, which is what Scrum ultimately is intended for.

As for the argument about Scrum prescribing roles, meetings and processes, I believe this is down to mindset. If rather than describing the Scrum framework by what it “prescribes” (I prefer the word “recommends” but I will continue to use the word “prescribes” because I see no harm in prescribing something within a framework that one chooses to use) we instead describe it by what it intends, Scrum is a framework for enabling teams to iterate over a product until the business or customer deems it valuable enough to ship. So, if you’re in a position where you want to develop a product iteratively (or at least incrementally) and want to put a team together to do that, Scrum is (potentially) an excellent choice. If you were to choose just Kanban for developing a product, which of course you could, then by default you will not be changing anything about the way you currently work. This is not necessarily a good thing.

For example, Kanban does not prescribe iterations but often Kanban implementations use some kind of iterative process (even if it’s just having a fortnightly review of the product) and teams do this for good reason. Sure, having iterations (Sprints in Scrum) doesn’t guarantee an iterative and incremental approach to building the product but it at least hints it might be a good idea. Even if you don’t fix your scope within the timebox it still makes sense to have (say) fortnightly demos and a chance for everyone to review and evaluate the product holistically. This is a sound and effective approach to software delivery, as borne out by the Agile Manifesto’s recommendation of measuring progress via working software and delivering value early and often.

Similarly, Kanban doesn’t prescribe cross-functional teams, so if you happen to have silos of developers, testers, designers, etc. working in a Waterfall fashion with hand-offs then you will continue to work in that way and not reap the benefits (at least early in the game) of forging collaborative relationships and working as a cross-functional team until such time as the kaizen to try this is agreed upon. This approach may be better in the long run in terms of organisational effectiveness, but in the short term it could be a slow path – too slow for the business to accept – to delivering shippable increments early and often and measuring progress with working software.

Being a framework Scrum prescribes meetings and roles, but without them there is no guidance toward effective delivery of value early and often or the aim of breaking down complex problems by building an end-to-end shippable product in increments as a team – in other words, if you take these meetings and roles away it’s not really a framework is it?! The meetings point out the importance of continuous business/customer feedback, prioritisation and trade offs (as does the Product Backlog), just-in-time planning, correcting your course, team process improvements etc. The roles point out that there is conflict in the traditional Project Manager role between serving the team and serving the business, and that an iterative (Agile) approach to software development requires coaching at both the team and business level, hence the Scrum Master and Product Owner roles.

A product development framework without some semblance of structure renders it useless as a framework. If the framework is abused (as it often is, but this is not the fault of Scrum) then its effectiveness will be diminished or negated completely. But this does not mean that Kanban is better than Scrum for product development or that Scrum should not be used. In the right context and with the right mindset, Scrum can be extremely effective.

To be honest it all depends on context (as it always does) but, put simply, if an organisation wants to change in terms of improving software delivery, Scrum may well be more effective than Kanban. If an organisation recognises that it needs to embrace a kaizen culture, not just to be better at shipping software, then pure Kanban could be the way to go. But trashing Scrum because it is not always good as an enterprise solution (ironically it can be but doesn’t prescribe how to do this) or because it defines structure (which guides towards effective practices congruent with Agile) seems glib to me.

Scrum and Kanban are different approaches for different contexts but can work beautifully together in certain situations (generally product development in a team and company of the right mindset to be open to new collaborative, approaches to delivering value). One can evolve into the other, either way. They are both interesting and have noble principles. There is much to learn, and teach, in both.