In Blog

The other day, inspired by the conversation Marcin Floryan started on twitter and carried on in a subsequent blog, I tweeted a follow-up question: Describe the difference between Kanban & Scrum in one word.

I should start by thanking those who took the time to contribute an answer and engage in the ongoing conversations afterwards.

Before revealing all of the responses, I should explain a purposeful difference in the questions that Marcin and I posed. Marcin’s question ‘Describe Waterfall vs. Agile in one word’ pitted one delivery paradigm against the other, whereas I attempted to avoid this in my question because, well frankly because too much breath has already been wasted on that debate.

Some of the respondents saw it as an unfair comparison, including Marcin himself. The intention with the conversation was just that, to have a conversation and not to spark some sort of celebrity death match – I was genuinely interested in the outcome. I hope with that said, that those that held back from responding might feel more inclined to leave a comment on this blog.

The Responses

Marcin Floryan was the first to respond with ‘cadence’
Paul Dolman-Darrall gave an initial response of ‘flow’ and then later changed his mind to ‘protective’
Mike Burrows was next with ‘evolution’ – however he did go on to point out that he saw a significant difference – to which I suggested that his one word would be ‘incomparable’
Bob Marshall suggested ‘conformance / compliance’
Wayne Peacock gave two suggestions ‘pull’ or ‘planning’
Kief Morris suggested ‘pull’ or alternatively, ‘batching’
Karl Scotland sided with Mike and suggested ‘perspective’
Olaf Lewitz said there was ‘none’
Mike Sutton agreed with Olaf and said there was no difference
Jens Meydam then suggested ‘rhythm’ (he later added ‘teamwork’ & ‘steps’)
Finally, Renee Troughton suggested ‘pseudoscience’.

That’s all very well, but what the heck does it all mean?

I’ve summarised my understanding of the answers with an explanation below:

Cadence / Rhythm / Flow / Planning

Scrum defines a series of events: Sprint Planning, the Daily Scrum, Sprint Review and Sprint Retrospectives – all of which must happen within a Sprint. The Sprint has a defined cadence (or rhythm), and so the events are all in synch with each other. Kanban on the other hand talks of cadence and specifically suggests cadences should be decoupled – indeed Kanban’s actual focus is on iterationless Flow.

Pull / Batching

Strictly speaking both Kanban and Scrum operate a pull system: in Scrum the team commits to the amount of work they think they can complete in the Sprint and so it is not a very pure implementation; Kanban differs here in that it focuses more on the work items and will only begin more work when there is capacity – it uses Work In Progress limits to ensure that not too much work is undertaken concurrently.

The difference between Kanban and Scrum when it comes to batching is more pronounced. Scrum batches by time; a Sprint, recommended as 30 days but often shortened to 14, constrains the amount of work the team undertakes – this is a very definite attempt to control batch size. Kanban takes a different approach, as I’ve stated, it focuses on the work items and their flow – the use of Cycle Time to track the progress of work items is not uncommon. Kanban itself does not explicitly state that you should focus on the batch size though. However, it is likely that in time, a focus on Cycle Time will uncover the need to reduce batch size.

‘Conformance / Compliance’ and Protective

Essentially, the suggestions here spoke of the approach that the two processes take – Scrum ignores the status quo and dictates how a development cycle should run, whereas Kanban specifically states that you should start with your existing process and seek to improve from there. This has led to the phrase ‘evolutionary, not revolutionary’ being used to describe the difference by some (see next heading). These two suggestions from Bob Marshall and Paul Dolman-Darrall respectively, created a good deal of conversation on Twitter as to the merits of the two approaches. I myself in my last company used an approach suggested by Jeff Sutherland called Shock Therapy – see a previous post on some of the experience here and so these suggestions struck a chord with me.

Evolution / Perspective / Steps

As alluded to above, these three suggestions all speak of the approach to change that Kanban and Scrum have. Kanban states that you should start with your existing process, visualise the workflow (Karl’s point about perspective) and make the process policies explicit in order to seek opportunities to improve using the scientific method. This would usually lead to small, incremental change. Scrum however is far more prescriptive and consequently is considered to take a big-bang approach. Scrum will also expose opportunities to improve and in fact, in my opinion it is far more clear about where the dysfunctions exist – it relies upon the rest of the organisation being prepared to change to overcome the issues uncovered. In addition Scrum doesn’t suggest the use of data to quantify the issues it exposes outside of its ecosystem, nor the potential benefits of the change and as a consequence, in my experience can lead to more resistance from those in the larger ecosystem.

None / No Difference

Here, suggestions from Olaf Lewitz and Mike Sutton also caused continued conversation. They struck a chord with me too, the suggestion being that both Kanban and Scrum could be used to bring about change and consequently, there was no difference.

Teamwork

While Kanban does reference the Lean principle ‘Respect People’, again, it doesn’t dictate any change per se and so as a consequence, does not focus specifically on the team. Scrum on the other hand has defined roles and a clear definition of who is in and out of the team.

Enough already, whose gang are you in?

I have to say that the conversation hasn’t necessarily helped me land on a definitive answer. I agree with Mike that it is usually ‘Kanban with’ – that’s possibly because I’ve never seen Scrum work at scale (I’m told it’s possible – I’ve just never experienced it for myself – quite the contrary) and I am drawn to Kanban’s principle that you should use models and the Scientific Method to make improvements but, and this is a big but, Kanban still seems lacking; it seems to actively avoid challenging the organisation too much. On the flip side this is where Scrum falls down in my experience – it challenges an organisation a little too much – I do wonder though if that speaks more of the prevailing mindset in organisations today than it does of Scrum though.

What of my own word then? Well I suppose I would offer ‘attitude’. Scrum acts like a spoilt brat, demanding everything its own way – eventually everyone tires of it and just ignores it. Kanban acts more like a middle aged duffer – always pointing out why your argument is wrong based on experience and data but is just as easily ignored.

Thanks…

Goes to the people that contributed to this blog post: Philip Black, Jabe Bloom, Sean BlezardRob Bowley, Mike Burrows, Mark Davidson, Paul Dolman-Darrall, Marcin Floryan, Torbjörn Gyllebring, Olaf Lewitz, Bob Marshall, Jens Meydam, Phil Murphy, Wayne Peacock, Karen Rodgers, Karl Scotland, Mike Sutton, Renee Troughton.

Thanks to them for taking the time to enter the conversation.

Subscribe to new blog notifications

Recommended Posts
Showing 28 comments
  • Amol
    Reply

    Empirical

  • KirkBryde
    Reply

    Nice! I originally thought of “flow”, but since that’s already been discussed, I offer the word “complimentary”. It actually goes against the grain of your specific question, but it fits perfectly if you rephrase your question to ask what Kanban and Scrum have in common. I like “complimentary” because it’s true, it’s thought-provoking, and it’s something that many people aren’t aware of. I challenge anyone to explain why a project team can’t apply Scrum and Kanban Method principles and practices simultaneously! 😉

  • David Rice
    Reply

    Timebox – Professional Scrum (scrum.org) has specific timeboxes to encourage order of work.  Kanban without other agile techniques does not.

  • Jim Benson
    Reply

    My word would be clarity. Which takes in perspective, but includes transparency and understanding. 

    • Dan Rough
      Reply

      Jim, thanks for responding. Can you explain a little more for me why you think Kanban and Scrum differ from a transparency point of view?

      • Jim Benson
        Reply

        Hi Dan

        While Scrum was designed to increase communication, and did compared to what likely came before, Scrum teams tend to wall themselves off from organizations during a sprint. The actions of the team are not apparent to the org during the sprint.  
        In addition, teams that wall themselves off tend to ignore the rest of the organization while they are sprinting. New work cannot flow into the group without major disruption and therefore the group does not seek information during the sprint.

        In a kanban-driven team … even if the team is doing Scrum with a kanban … the visual control creates an immediately updated display of activity done by the team. This “heads-up” display is powerful both inside and outside the team. It not only encourages the rest of the org to know what the team is doing – it encourages the team to ask “what’s coming next” and “where did my work go?” 

        The limiting of WIP also makes completion paramount, which means that when you are working on something and when you complete something you have a greater degree of ownership of it. This means that you are more likely to want to make sure it was relevant work, that you had the information you needed to do a good job, and that others know you did it and why.

  • EnergizedKris
    Reply

    I’d like to offer up “Disruptive” in an analogy to products that disrupt a market, the two approaches differ on how it might disrupt your org – with potential positives and negatives in both approaches and depending on context, just in the same way a company launching a new product/service might effect its existing portfolio. 

    I think the sections on conformance/compliance/protective and evolution cover my perspective on things.

    • Dan Rough
      Reply

      .@EnergizedKris Thanks for your comment on the difference between #kanban & #scrum blog – it’s an interesting one!

  • Jaap Schuttevaer
    Reply

    (over)simplification

    • Dan Rough
      Reply

      Nice – very succinct – thanks!

  • Paul Littlebury
    Reply

    My own opinion – the only real difference is the all-important WIP rules, but that is key difference that makes Kanban more effective for development planning.

    • Dan Rough
      Reply

      Thanks for your entry Paul.

  • Renee Troughton
    Reply

    Just wanted to clarify here… Scrum is the one that I attribute the pseudoscience logic to. Reasoning as per twitter was primarily to the way in which both of them are measurable. 

    In Scrum throughput is measured with velocity. But change may affect the velocity. Additionally wait zones are not tracked (nor their impact in end to end delivery times). The cross functional nature of teams is also hiding or working around inherent problem in the flow. 

    Comparatively Kanban measures not just the end to end story time but also the time at various stages of the flow including wait times. The impact of change is measured and controlled through the throttling of expedites. 

    • Dan Rough
      Reply

      Hi Renee, thanks for your response. I’m going to have to ask you to clarify a little more for me. My interpretation of your comment is this: Scrum measures improvement by tracking the team’s velocity (which only focuses on one element of the development process) which hides a lot of valuable information and susceptible to lots of common cause variation. Kanban on the other hand takes a far more systemic view and uses measures accordingly meaning that it does get to see a lot more of the problems that surround the area of narrow focus that Scrum has.

      If all of that is a fair interpretation, I’m not sure I understand one part of your response fully – you said “The impact of change is measured and controlled through the throttling of expedites.” – could you explain that again for me?

      Thanks, Dan.

      • Renee Troughton
        Reply

        Hi Dan,

        In Scrum change is generally not allowed inside of the sprint (sacred timebox yada yada). That said, I see a lot of teams failing to push back of change inside of the sprint. Some might say that the team is in error here, but if a team is working operationally (ie supports a system already in production) and a Severity 1 defect occurs that requires a hotfix then there is no doubt that the change has to occur. This is where applying Scrum by the book can get difficult because change needs to be allowed.

        In Kanban an expedite trumps all other work and allows the work in progress limits to be  exceeded by one. Because we don’t want this “trumping” to occur frequently as an implementation rule we only allow one expedite at a time (some say per flow, others per flow state). This implementation rule is effectively throttling the amount of change that will impact the flow. If change is important but all other work in progress is still important then it just goes to the top of the backlog and gets pulled naturally. 

        In a Process Control Chart we measure the cycle time of each card through the flow. By measuring expedites and visually making them pop (eg using a different colour for them) we can see the impact that the expedite has on subsequent stories’ cycle times. 

        • Dan Rough
          Reply

          Okay, thanks for the clarification – I think I now understand your point.

          To extend the conversation a little – when you mention the expedites, are you referring to Classes of Service because strictly speaking you could reserve capacity strictly for an expedite class of service meaning that other more pedestrian items wouldn’t be disrupted at all. Of course, having capacity that is unused for large portions of time is quite some investment and one few companies would be unwilling to undertake, I’m sure.

          • Torbjörn Gyllebring

            Dan, Renee, 

            the typical way using Classes of Service to both meet expected lead times *and* provide the possibility to expedite items is to allocate some reasonable amount to a lower priority class of service, often intangibles (maintenance, upgrades, thinking) and simply expect more variation in this class. When expedites or unexpected sources of variation hit your fixed date or high priority items this lower class can be used to absorb the variation thus enabling you to do the impossible. Both deliver expectations and absorb the extra work. 

            This happens naturally in many cases, making the policy explicit accelerates learning, understanding and provides safety for those involved. 

          • Dan Rough

            Yep – thanks – while the suggestion I made was as I acknowledge not necessarily feasible in most circumstances, in practice I can imagine it working exactly as you define.

            In the team I work within at the moment for instance, we have two classes of service: fast & slow – fast things are allowed to disrupt slow things, not the other way round.

    • Torbjörn Gyllebring
      Reply

      Renee, 

      I like how you highlight one of the backsides of swarming, that it might actually help disguise problems & unevenness. 

      What I don’t fully understand is your distinction between how Kanban & Scrum measures throughput. 
      There’s nothing in the Kanban Method (except for the principle to manage flow) that dictates how one should measure throughput although the community has good experience with what you mention.

      Additionally ‘Velocity’ as a throughput measure doesn’t sit well with me since it seems to imply it could be compared & aggregated across teams (which it cannot). 

      I’m surly missing something, what’s your take on the above?

  • Torbjörn Gyllebring
    Reply

    Hi Dan, 

    I think one often overlooked aspect of the Scrum & Kanban comparison and debacle is the misunderstanding that you can somehow do “Kanban” to deliver software.

    Kanban explicitly requires you to choose a delivery process (or as it often plays out religion) and then you apply Kanban to your chosen faith to evolve a context specific flavor of it.

    Scrum might be that religion; but you simply can’t given an empty office start with Kanban and claim to have selected a process to deliver software.

    Now given that Kanban comes with a few values & principles it’s a commonly emerging pattern to dismantle iterations & decouple cadence – if your starting point is Scrum then arguably you’re no longer doing Scrum (which is fine non-Scrum can rock) but neither are you “doing Kanban”. 

    I think most people don’t like the discomfort of no longer having a precooked labeled process & thus simply apply the name of the evolutionary change method that took them there (Kanban) to it which is, in all honestly, a misnomer.

    • diaryofscrum
      Reply

      This hits the nail on the head for me. It describes what we are doing and a few others that I’ve met. I’m fine with not labeling it as that would suggest it was fixed, I guess ‘agile process’ will do for the developer in the street…

      • Dan Rough
        Reply

        Tom, I think we all want to belong to something hence our desire to apply labels. In some cases we want to be able to differentiate ourselves from others that we perceive not to be as good as us.

        Isn’t funny how few people actually talk about the way in which they’re delighting their customer instead of quickly rushing to tell you how agile (or whatever) they are?

    • Dan Rough
      Reply

      Torbjörn, thanks for such an eloquent reply.

      I actually removed a piece of commentary from this blog prior to posting as it was taking the post too far away from its core (plus it gives me more content for another day :)) which essentially said that I don’t believe that there is such a thing as a pure process – there are starting points, one of which is Scrum. I went on to say that Kanban is a type of meta process, providing its users with an abstraction of the status quo and that the original intention of the status quo now present in most cases was actually to meet a given purpose, however, and for a reason that I need to explore a little more, that purpose has been lost; Kanban and other meta processes allows its users to view the existing process and attempt to determine its suitability against the purpose, and to evolve accordingly.

  • Rob Bowley
    Reply

    I meant to add “discipline”. I’ve found Kanban requires a lot more discipline than Scrum. Scrum gives you more protection via up front commitments and a clear line in the sand. Not so much the case with Kanban – it’s easy to break WIP limits and end up with too much in progress and churn. 

    • Dan Rough
      Reply

      That’s an interesting one Rob. I think they both need equal amounts of discipline, just different types: Scrum requires you to stick at it’s process, no matter what whereas I think that Kanban’s suggestion that you should make your process policies explicit means that you need to be disciplined enough to ensure that you’re adhering to your own process policies (WIP limits included).

      At the end of the day, all of this stuff is hard, no amount of process is ever going to replace the need for people who want to find better ways of working together in an effort to deliver something to their customer – hence my conclusion.

      Dan.

  • Karl Scotland
    Reply

    Hi Dan

    My suggestion of ‘perspective’ was more than just visualising the workflow. I think all the various suggestions are different perspectives.  Evolution or revolution is one perspective, which is where I started. However, from the perspective of the basic purpose of improvement, there is no difference as Mike/Olaf suggested. So ‘perspective’ was an attempt to sum up in one word, something that can’t be described in one word 🙂

    Karl

    • Dan Rough
      Reply

      Thanks for commenting Karl – I had to read it a couple of times to make sure I got it 😉 but I think I have now.

      My apologies for misinterpreting your original suggestion.

      I’d absolutely agree that the differences can’t be summed up in one word – it was an enjoyable exercise in attempting to do so though.

  • ojuncu
    Reply

    Lovely ,  may word to differenciate is “team” .
    I kind of feel that Scrum empowers teams to focus on a powerful common goal, kanban can de described prettyy well as personal commitment to improve a flow. How can we contribute to furtehr discussions?I’m interested for ages to have a difference between Lean and Agile as I don’t see any. ReallyAs long as we agree that Agile is not only for software… . 
    cheers,
    Oana

Leave a Comment

Predicting the Future