A Scrum and Kanban Comparison

In a recent thread on the kanbandev list, Tim Uttormark asked about how Kanban handles teams with different dysfunctions without the Sprint timebox and associated meetings.  He gave the following example:

In Scrum, all tasks for the iteration are estimated by the team in sprint planning. Tasks assignments are not known at the time of sprint planning. The task estimate results from a team consensus, so the one doing the work on a task is not (solely) responsible for creating the estimate.

In my example, Harry (due to his incompetence) and Bill (due to his laziness) would fall short of the standard set by the team’s task estimates. Jeff’s behavior will not point as clearly to him as the problem, but will still be manifested as a team issue. Since he is highly skilled, he is probably able to produce at a higher rate than the average team member, and he can finish his tasks on time despite overengineering them. The team however would be better off if he stopped at “good enough”, finished early and moved on to other tasks. Jeff’s dysfunction would likely be manifested as the team missing their sprint commitments — the team needs the above average performers to complete more than their share of tasks to compensate for the lesser performers. In this case the team’s estimate of how much work they can commit to completing in an iteration provides a standard for comparison of team performance. Of course this can be gamed too, but requires more of a team conspiracy than just individual efforts to undermine it.

I responded by trying to map the Scrum process onto a Kanban process in order to show how a kanban system might deal with the same situation.

Sprint Planning is where the team collectively and collaboratively plans and commits to a small increment of work. As you say, this meeting will highlight any mismatches in understanding of the problem or solution by generating the Sprint Backlog with tasks and estimates, such that the whole team has a common understanding of what needs doing and how long it should take. Harry’s incompetence can be mitigated because he should have a better understanding of the solution. Bill’s laziness can be mitigated because he has been part of the estimation process, and Jeff’s over-enthusiasm can be mitigated because scope has been clearly discussed.

The Sprint Review is where the team are accountable for their Sprint commitment. This accountability should again mitigate for Harry, Bill and Jeff, because they have to demonstrate their progress and explain variation from the plan.

The Sprint Retrospective is where the team can explore reasons behind variations from the plan (and strengths and weaknesses in general) and can inspect and adapt in order to learn and improve. Over time, this can also mitigate individual weaknesses.

So for Kanban…

Sprint Planning becomes Feature Planning. Rather than planning a timeboxes worth of product increment, the team plans a single valuable increment at a time – sometimes referred to as a Minimal Marketable Feature (MMF). The team limits the amount of work in progress in order to minimise the cycle time of these MMFs. Once they have completed and released an MMF, the pick up a new one and start by planning it. The Planning can happens as a team, and break down into tasks and estimates as per Scrum, thus bring the same benefits and mitigating weaknesses in the same way. A possible downside is the break in flow that may happen when you bring the team together. A solution to this could be to keep a prioritisation and planning cadence – e.g. a weekly meeting to decide what the team will be working on next, and to plan it out. The frequency of this meeting will probably depend on throughput. The more frequently the team is able to complete and release work, the more frequently this meeting can be scheduled. A difference between this planning cadence meeting and a sprint planning meeting, is that the planning is ‘de-coupled’ from the release. In other words, whatever is planned does not have to be completed and released before the next planning meeting. In an ideal world, however, the MMFs are able to be small enough such that they can be completed and released within a week. In this case, Scrum with weekly Sprints can look very similar to Kanban.

Because of this ‘de-coupling’ of planning and release, a commit and deadline is made per MMF. This is sometimes referred to as a Service Level Agreement (SLA) between the team and business. The SLA says that the team will deliver features X days from when they are prioritised in the planning cadence, and is usually derived from past measurement of cycle-time. Where there is variability in the size of MMFs, different SLAs can be set for different sizes. Standard Scrum story point estimating can be used to classify the MMFs into different SLAs. A Due Date Performance (DDP) metric can also be measured, which is the percentage of MMFs delivered within their SLA. This SLA and DDP is what creates the equivalent team accountability in Kanban. I blogged some more about this here.

Sprint Review can still happen as part of the Release cadence. However, as we have de-coupled planning from release, this can happen as frequently as necessary, depending on the cost associated with a release. In the ideal world, this cost is zero, and you could release small MMFs daily. In this case, a small review of each MMF as it is completed might be appropriate. If there is a small release process the team needs to go through, then a weekly release cadence might be better, with a weekly Review. Whatever the frequency, the release cadence brings the same accountability for what has been delivered, and how long it has taken.

Sprint Retrospectives, similarly, can still happen with their own cadence. Kanban does try and shift the emphasis on the improvement to be as continuous and ‘kaizen’ as possible, but a fortnightly or monthly retrospective would certainly be a good thing to start with. Again, the retrospective brings the same benefits as in Scrum. I blogged some more about this here.

So I’d say in summary that a kanban approach includes all the elements of Scrum (including stand ups as well), but decouples them from all being tied to the Sprint. This can create a more natural process. On the other hand, it can also be less clear what to do when as its not so defined.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

8 comments on “A Scrum and Kanban Comparison

  1. Thanks for that snippet. I’m not reading the Kanban list as often as I was, volume’s gone up (and posts seem to have got longer) so I’ve been missing some stuff.

    In the situation Tim describes I’m not sure any process – Scrum, Kanban, CMM can fix the root cause. That’s because the cause is the people.

    Tim’s scenario makes a number of assumption: Harry is incompetent, Bill is lazy, etc.

    That is, Tim (or the manager in the scenario) is operating with this mental model. Once they assume Harry is lazy it becomes self-fulfilling. Why would a Scrum planning meeting, a retrospective or a release fix this problem? It won’t.

    The manager needs to reset their model, talk to Harry, find out what might be inhibiting Harry’s performance, etc. etc.

    I think claiming that any system will fix these kind of problems is a little naive. The best a process can do is show they exist.

  2. Pingback: Dew Drop - February 12, 2009 | Alvin Ashcraft's Morning Dew

  3. Karl,
    I enjoyed the post, but I have a question from what I’ve been reading elsewhere about lean and Kanban. I see the point you are trying to make with comparing Kanban to Scrum, but aren’t estimates also seen as waste? Why would you carry this facet of scrum that appears to be dropped by most of the lean people who (I think) consider it waste? Perhaps I haven’t quite grasped the lean principle here too?

  4. Hi Karl,

    Your explanation of Kanban is by far the clearest I’ve seen thus far. It is clear to me that it is working for you. My concern though, is that it may not be working for the reasons you think. A lot of emphasis is made on where your process overlaps with lean thinking, but there are still gapping gaps that go undescribed. For example, how are MMF levelled so that they are similarly sized? How much effort is spent levelling MMF and what is the return on that investment? Could what is going on in these “gaps”, be as equally if not more important as the aspect you choose to describe?

    A jump up thought is that it may be better explaining what you actually do day-to-day, the people involved, their interactons etc, sort of in a narrative – “a day in the life of a Kanban team” – Similar to what Ron Jefferies is doing with the fictional “Kate O’Neal”.

    This would be a true primary source, and would leave the interpretation to the rest of us. The post analysis you present in Lean language could be just one interpretation of what is actually happening.

    What Kanban seems to be missing is a silent witness, like a Alistair Cockburn, observing and taking notes. Instead the main reporters are also the main protagonists, which has the potential for “post rationalisation”. If you know what I mean.

    My last point. A small group of self-organised people collaborating effectively can solve a multitude of problems in a multitude of ways. We have a tendency to extrapolate systemic behaviour where infact there is just chaos. The assumption being that chaos is a bad thing. Chaotic behaviour is actually just part of being human, and part of the creative process. Allowing for chaos, whilst retaining discipline seems to me to be the essence of Agility. In your explanation of Kaban, this essence is noticeable by its absence.

    Paul.

  5. Pingback: links for 2009-11-05 | Nathan Jamin’s Weblog

  6. Pingback: links for 2009-11-06 | Nathan Jamin’s Weblog

  7. Hi Jason,
    You’re right. Because a kanban system measures throughput and cycle time, rather than planning into a timebox, estimation can be considered waste. I glossed over this to avoid muddying the water too much.
    Karl

Leave a Reply