What’s the Difference Between a Scrum Board and a Kanban Board?

During a recent kanban training course, this question came up and my simple answer seemed to be a surprise and an “aha” moment. I tweeted an abbreviated version of the question and answer, and got lots of interesting and valid responses. Few of the responses really addressed the essence of my point, so this post is a more in-depth answer to give more detail.

When the question came up, I began by drawing out a very generic “Scrum Board” as below:

Everyone agreed that this visualises the basic workflow of a Product Backlog Item, from being an option on the Product Backlog, to being planned into a Sprint and on the Sprint Backlog, to being worked on and In Progress, to being ready for Accepting by the Product Owner, and finally to being Done.

To convert this into a Kanban Board I simply added a number (OK, two numbers), representing a WIP limit!

And that’s it. While there are many other things that might be different on a Kanban Board to do with the flow of the work or the nature of the work, the most basic difference is the addition of a WIP limit. Or to be more pedantic you might say an explicit WIP limit, and as was also pointed out (although I can’t find the tweet now), its actually creating a pull signal.

Thus, the simple answer to the question about the difference between a Scrum board and a Kanban board is that a Kanban Board has WIP Limits, and the more sophisticated answer is that a Kanban Board signals which work can and should be pulled to maintain flow.

Of course, this isn’t to say that Scrum teams can’t have WIP limits, or pull work, or visualise their work in more creative ways. They can, and probably should! In fact the simplicity of just adding a WIP limit goes to show how compatible Scrum and Kanban can be, and how they can be stronger together.

A Pattern for Using Scrum and Kanban

I’ve noticed a pattern that I’ve found myself using recently when I’ve worked with new teams that makes use of both Scrum and Kanban ideas. I’ve already said that I believe the two are complimentary, and this should help show how.

  1. I’ll often begin with a “Canonical Scrum” implementation. This gives a relatively simple introduction due to the ubiquitous language, standard training and often client demand. I also find that its a very good way of quickly exposing the real underlying workflow. Stressing a team by introducing a new way of working soon makes the current way of working apparent.
  2. After a few Sprints,once the team understands both what the desired outcome is and the current context is, I’ll ease back into what many people might call “ScrumBut”. Rather than continuing to highlight and struggle against impediments and constraints which are out of the teams control, I will apply kanban aspects to help the team acknowledge, but deal with their context without feeling dogmatic.
  3. Finally I’ll help both the team and the organisation improve, by seeing where the issues are, whilst continuing to be able to deliver. Sometimes the current workflow is appropriate for the team and it is smaller batches and queues that are needed. Sometimes the current workflow is a symptom of silos and poor collaboration.

So I find Scrum to be a good way of showing teams what could be possible, and finding out where I can help make improvements. Then I find Kanban a good way of enabling a smoother transition for those improvements in a way which is appropriate for the teams’ contexts.

Kanban and Scrum – Intention and Implementation

In my last post I introduced the idea of a PVC System – one which exemplifies Pull, Value and Capability – and closed by posing the question as to whether Scrum could be considered to be a PVC System. In answering that question myself, I realised that there is another distinction which I will describe in this post. In doing so, I am also re-entering the great Kanban and Scrum debate, with the goal of learning rather than fighting!

The XP Community popularised the concept of programming by intent; writing code which describes what it is doing rather than how it is doing it (programming by implementation). I believe the same distinction can be used to describe methods, and can help differentiate Kanban and Scrum. Kanban is an intention-revealing method. The intention is to reveal the workflow, visualise the work, limit work in progress, establish a cadence and continuously improve. How to do that is up to the team. They can use any workflow, visualisation, WIP limits, cadence or improvement mechanisms. Scrum on the other hand is an implementation-revealing method. The implementation is described in terms of the Sprint and the associated roles, meetings and artefacts. Even if the implementation is described in abstract terms, as Tobias Mayer does, (and Tobias’s interpretation of Scrum is one I respect greatly) I still consider it to be focussed on implementation.

This is not to say one is better than the other. An implementation is ultimately required, and Scrum has proven to be a very good one with which I have had considerable success. But is Scrum a PVC System? I think it can be, if implemented with an intention-revealing mindset. If the Sprint, roles, meetings and artefacts are implemented in way which reveals the workflow, visualises the work, limits work in progress, establishes a cadence and continuously improves, then it will be implemented with the right intent. I expect that most cases of “Good Scrum” will fall into this category. On the other hand, if the Scrum Sprint, roles, meetings and artefacts are implemented in a mechanical way, then I suspect that the workflow will remain hidden, the work will not be visualised, work in process will not be limited, a cadence will not be established, and continuous improvement will not happen. This is when we get cases of “Bad Scrum”. Thus ScrumBut is not when the Scrum practices aren’t followed per-se, but when they are followed with the wrong (or no) intent.

So Kanban and Scrum are like apples and oranges (to jump to an different analogy). Both are good for you, and both can go together – with other fruit – to create a tasty fruit salad. But they are different. Kanban is intention-based and Scrum is implementation-based.

Scrum Anti-Pattern: NOT Prioritising Stories Within Sprints

Craig Dickson has published an article on Agile DZone claiming that prioritising Stories with a Sprint is an anti-pattern. He blogged this in December last year, when I noticed it and grumbled on twitter, but no more. Now that its re-appeared on DZone I feel compelled to say something, and that it warrants a blog post of my own rather than a comment.

Craig says that a Scrum team commits to a “set of Stories by the end of the Sprint” (his emphasis), and that prioritising within the Sprint means that the “commitment evaporates”. That sounds to me like committing to, and delivering, a batch of Stories. I’m sure notable Scrum luminaries have assured me that the Sprint is not a batch. Craig even suggests the Scrum diagrams should represent the Sprint Backlog as “one single large block of work”. What about flow? What about limiting work in progress to improve flow? If shorter Sprints are good because it encourages prioritisation and limits work in progress, why not prioritise work and limit work in progress with the Sprint?

Craig goes on to suggest that rather than prioritising a Story within a Sprint so that it can “meet a business need”, the PO should “reach out and educate the necessary stake holders about the Scrum process”. This sounds to me like Craig is recommending that Scrum dictates how the organisation is run, and that this is more important than meeting a business need. I prefer my processes to support and enable organisations to meet their business needs. Scrum should be a means to an end, not an end in itself. My view of Agile is that is about being responsive to business needs, not forcing organisations to wait until a convenient date. A cadence should be useful, but not a restriction.

Similarly, Craig says that prioritising Stories within Sprints is bad if it creates “implementation dependencies between Stories”. I prefer to think that a Product Owner should be able to ask for, and have delivered, increments/iterations in whatever order creates the most value, and not be constrained in this way by process policies about how Stories should be written. Worse still is the suggestion that any dependant Stories should be scheduled into separate Sprints. How is that being responsive to business needs and encouraging flow?

Finally, I think that Craig is missing a trick. In the same way that short Sprints focus a team’s technical and creative capabilities to figure out how to get to DONE in a short time-box, so too will prioritising Stories within a Sprint focus a team to stretch their skills even further. A team that can deliver and release a single Story every day or so is surely in a better position that one which can only deliver a batch of Stories every week or so.

Craig concludes by observing that “There is nothing in the Scrum process that talks about Story priorities within a single Sprint.” Correct. But that doesn’t make it an anti-pattern, in the same way that TDD is not a Scrum anti-pattern because Scrum says nothing about TDD. Rather, I’d say that NOT prioritising stories within Sprints is the anti-pattern.

Process Safeguards and Ski Slopes

black ski slope One of the joys of working as a coach for EMC Consulting are the regular opportunities to have deep conversations on various topics with my colleagues when we are in the office together. For example, earlier this week myself and Simon Bennett began to discuss way of talking to our clients about process such that we can guide them towards the most appropriate choice. However much we may have our preferred approaches, they may not always be the best solution in any context. In the course of the conversation we compared various styles including waterfall, scrum and kanban, and looked at them on various scales, including risk, reward and control. None of these seemed satisfying as a language to use, until Simon suggested safety.

Different processes have different levels of safeguards built into them. Safeguards are used by processes to compensate for low skill, low maturity or low trust, but they also reduce speed or reward. With a waterfall process, the heavy up-front documentation is a safeguard to compensate for low trust (and often low skill and maturity). When a customer does not want to collaborate, then waterfall provides safeguards aimed at avoiding them rejecting the final delivery (not that those safeguards always work!). At the other end of the spectrum, extremely productive teams often have very few safeguards because of the high trust, collaboration and capability. Those safeguards that are in place (such as automated tests) are very different. Not having safeguards doesn’t make the process dangerous. It means that team doesn’t need them. So when we talk to customers about process, we can talk about the appropriate safeguards needed for the amount of trust that exists, the capability of the team, the desired delivery speed etc.

While exploring this idea, I became aware that at various points I was referring to kanban at different places on the safeguard continuum. At the high safeguard end was a kanban based process that looked like waterfall, but was limiting WIP and reducing queue and batch sizes. At the low safeguard end was a kanban process with extremely low WIP, no estimation and pure pull. That’s quite a wide range of processes. Similarly, we had Scrum down as a range on the continuum. Towards the high safeguard end, Scrum-but changes Scrum to add safety. Towards the low safeguard end, a highly productive Scrum team will just be using the raw essence of Scrum. Even at this end, however, the Sprint boundary in Scrum could be seen as a safeguard. It’s the opportunity to pause and reset if things are going awry.

In trying to articulate the different types of kanban system in terms of safety, I gave a nod to XP and labelled low-safety kanban “Extreme Kanban”, and high-safety kanban “Safe Kanban”. Not entirely happy with this we bounced some more ideas around and came to the Ski Slope metaphor. “Extreme Kanban” became “Black Kanban” and “Safe Kanban” became “Blue Kanban”. A further iteration led us to “Off Piste Kanban” and “Nursery Kanban”. The ski slope metaphor works quite well at a number of levels. Its a nice way of looking and risk and reward. As a beginner at skiing I don’t want to take much risk, but can get some reward on the nursery slopes. As my capability improves, and as I trust my ability (and instructor) more, I’m prepared to go onto more difficult runs and take more risk to get more reward. Nursery slope groups are generally more controlled, staying in a single file group. As capabilities improve, individuals are given more freedom to try things out for themselves. If I were ever to become an expert, I’d be happy to go off piste to get a high reward. Additionally, when I get to a level where I go off piste, I probably don’t need an instructor anymore, but I may need a guide.

Using the ski slope metaphor allows us to decide what level of process to start a new team with based on how good they currently are. We may want to stretch them a bit, but we may not want them to go straight onto a black run process. We also want the team to be able to move up to more challenging but rewarding levels as they improve. This is one of the reasons I prefer a kanban based approach. I believe it allows teams to start with an safer process to begin with and move to more rewarding processes later by removing or changing safeguards, as opposed to pushing teams straight into a process with less safety before they are ready.

Outcomes and Sync Steps

I met up with Jean Tabaka last week for a coffee and we chatted over various things, including Lean, Kanban, “The Don”, Tufte, and Systems Thinking. One of the other areas was around the origins and original intents of Scrum. Jean mentioned an early paper(*) by Jeff Sutherland, written before the current terminology became standard, where he described his process in a very simple way

  1. Decide and agree on an Outcome, in terms of working software
  2. Use daily Sync Steps to decide how to best achieve the outcome

Since we had that discussion (which also touched on GTD), I have found that this a great a way of describing the essence of Agility. Inevitably it has also triggered thoughts on ways of comparing and contrasting Kanban with more traditional Agile methods such as Scrum.

In a Scrum based approach, the Outcome is defined by the Sprint Goal, with the Sprint Plan being a means of making a commitment to the Outcome. There is a single Outcome, which is constrained by the length of the Sprint. The Sync Steps are provided by the Daily Stand Up Meeting.

In a Kanban based approach, the Outcomes are the limited work items in the system. There can me multiple Outcomes in progress at a time, but the WIP limits constrain the Outcomes. Planning, and as a result any commitment (or SLA) on the Outcomes is done per Outcome, and Just In Time. The Sync Steps are usually provided by the same Daily Stand Up Meeting, but could also be formed by other forms of Cadence.

So both Scrum and Kanban focus on team Outcomes, with regular Sync Steps to achieve the Outcomes. The way in which those Outcomes and Sync Steps are managed are different.

(*) Unfortunately, I don’t have a reference to this paper. If you recognise it, please let me know!

Update: Jeff actually calls them SynchSteps. References can be found in this 2001 paper, and in early emails. He also refers to Outcomes as Mutations.

Is Kanban A Relabeling of Scrum?

Firstly, this post is not an attempt to be divisive or competitive. Instead it is meant to be exploratory. What would it mean for the statement in the title to be true? Actually, the full statement was “People have so misunderstood Scrum, that they’ve reinvented it and called it Kanban”. It was made by Jim Coplien at Scan-Agile, after (but not necessarily the result of) a conversation over dinner where myself and a few others were describing how we used Kanban. Each time we described different aspects of our processes, Jim would say something along the lines of “but I do that with Scrum”.

So what would it mean for people to have so misunderstood Scrum that they have reinvented it and called it Kanban?

  • It might mean that at their heart, Scrum and Kanban have the same intent. That both are really focussed on helping teams think about their processes in order to help them succeed.
  • It might mean that the way that Scrum was originally articulated (and is still articulated according to the latest Scrum Guide) was not as clear as it could have been. That teams might misconstrue the focus on roles, meetings, artefacts and rules.
  • It might mean that there are alternative ways of articulating the same intent. That teams might find alternative articulations valuable.
  • It might mean that Kanban can be equally misunderstood. That teams might be bewildered by a less prescriptive approach.
  • It might mean that we should spend more time on understanding how to help teams solve their problems and less time arguing and fighting over preferred solutions.

These are just some of my thoughts. They do not mean that I think Scrum is bad – just not perfect. They do not mean that I think Kanban is perfect – although it’s currently my first language.  The topic drew a good crowd at the Scan-Agile Open Space and we had a good discussion. What else might it mean?

Kanban and Time-boxes

I had a brief exchange of tweets with Ron Jeffries, Keith Braithwaite and James Shore after the Miami Lean and Kanban Conference ended regarded Kanban and its compatibility with XP and time-boxes. Unfortunately I wasn’t able to follow up immediately, due to an urgent (and eventful) trip to South Beach 🙂 Rather than try and follow up late on twitter, I’ve decided to post my thoughts here to try and clarify my ideas.

The discussion started following a tweet about Kanban being easier to introduce than Scrum. This seemed to be a common theme at the conference, with several experience reports confirming what I have already written about whether Kanban is only suitable for mature teams. This led to the question of how much change (or not) a Kanban approach requires, which is where I jumped in.

A kanban approach introduces tools to visualise and measure queues and work in progress. While this is a change in process measurement, it doesn’t change the process itself. However, having highlighted the existence of queues and work in progress, it becomes easier for the process to be changed to specifically fix the issues highlighted. Thus a Kanban system sets a team up to begin continuous improvement. Time-boxing, used by XP and Scrum, is one way to manage queues and WIP, which is why they can be such effective processes, and why shorter time-boxes are becoming more popular. There are other ways of managing queues and work in progress, however, and thus Kanban is agnostic to time-boxing. This does not mean that XP is Kanban system however, because XP implicitly, rather than explicitly, manage the queues and work in progress.

Further benefits of time-boxing are the focus that they give, particularly given the finite or limited resources (i.e. people) within a team. Time-boxes give this focus not only by limiting the work-in progress, but also by setting the end of time-box as an SLA for when the work will be completed. Again, Kanban doesn’t lose these benefits, but provides for alternate means to limit work in progress and set SLAs.

To summarise, I believe that a Kanban approach is compatible with XP and Scrum in that it has a focus on managing queues and limiting work in progress, but also introduces alternate ways to achieve these goals which can be used alongside the XP and Scrum tools such as User Stories, TDD and Retrospectives.

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.

Kanban and the New New Product Development Game

One of the primary origins of Scrum is “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka, published in the Harvard Business Review in 1986.  This is the article in which the contrast is made between a traditional sequential or “relay race” approach and a holistic or “rugby” approach. Hence  the name Scrum was derived.  As part of their explanation of the differences between the approaches, the authors describe three types of approach:

  • Type A – single phases, proceeding exactly sequential
  • Type B – single phases, overlapping at their borders
  • Type C – multiple phases, overlapping each other

Phase Types

The Type C diagram was in my mind when I was putting together the diagrams towards the end of The Anatomy of an MMF, and I think this approach actually describes a Kanban based approach pretty accurately, where we recognise and allow phases to exists as necessary, but at the same time encourage whole team collaboration.

Jeff Sutherland has also reinterpreted the classifications to describe how Scrum’s Sprints progress:

  • Type A – single Sprints, proceeding exactly sequential
  • Type B – single Sprints, overlapping at their borders
  • Type C – multiple Sprints, overlapping each other

Another way of describing this evolution could be to say that Type C is multiple, overlapping MMFs, where each MMF is variable length and not time-boxed.  Its worth noting that The New New Product Development Game makes no mention of time-boxes!