Scrum or Kanban: What’s right for my team?
Part 2 of a series focused on helping your team choose an agile framework
In a previous blog post, I covered the six steps to choosing between Scrum and Kanban as your primary framework. Summarizing anything to a few steps will give you a place to start and you’ll probably want more, but what if you’re just not sure if the team should be a Scrum team or a Kanban team? Let’s walk through Step 2, from that blog post, in more detail.
If you are in the technology industry, you have heard of Scrum and even say that you have “done Scrum” before and admittedly might have been more “Scrum’ish” versus a purist approach in the last 10 years or so. Kanban, literally meaning “signboard” or “billboard” in Japanese, was invented in the 1940’s as a result of research in lean manufacturing. It has made its way into process development, improvement methods and on to knowledge work in the early 2000’s. You’ll even see both Scrum and Kanban called out in the Scaled Agile Framework® (SAFe®) because more and more teams are working together for larger, more complex solutions that benefit from both styles. So if you have a choice between the two, what are the basic components that make a team a Scrum Team or a Kanban Team?
Seems pretty different right? Are you wondering why Kanban teams don’t have roles? I thought the same thing when I was introduced to Kanban back in 2009. “How are they going to know what to do?” I asked the coach. His response “They figure it out.” I wasn’t a bit skeptical at that point. But with time, I realized that the teams that choose Kanban become highly disciplined; they create social norms and working agreements that work for them as individuals and for the context of work that they do. I once made reference to a Kanban Master equivalent on a Kanban team to manage the backlog when one of the teams decided it was needed. In the moment, I made it up but it seemed to stick. A few years later, they still call some of their Kanban members Kanban Masters because they needed coaching from someone that had more expertise. After more than seven years of teaching and coaching, I can say with certainty that not all of Kanban or Scrum teams work exactly the same but they do have a lot of common practices (I’ll get into that later).
Aside from some differences in lingo and the Sprints, they look mostly similar, right? User Stories were used as far back as Extreme Programming and have been a key element in the Scrum practice but Kanban uses the term “work item” because the traditional format of writing a user story is not always applicable to the work that a Kanban team does so we use a more general term like work item. I’ve also seen Kanban teams writing user stories because they used to be Scrum Teams or learned it at some point and they wanted to continue. We’ll talk more about the type of work Kanban teams do later in this post, so keep reading!
The biggest differences between Scrum and Kanban is that Kanban is a steady flow of work coming into the system (think “big visible board” here) rather than kicking off a timebox, closing it out and kicking off another timebox, closing it out and kicking off another timebox, closing it out… you get it. To really appreciate the difference, take a look at the two team boards below. Can you tell from each of the states (columns) which one is for the Scrum Team or the Kanban Team?
Notice that the first board has a Product Backlog and an Iteration Backlog.
The second board MIGHT be for a Kanban team because they have numbers for each state which are called “WIP Limits” or “Work In Process Limits.” It’s a technique that all Kanban teams use to limit how much they are actively working on. Scrum teams use sprints to limit their work for that timebox. (By the way, “Iteration” and “Sprint” are used interchangeably all the time – I know! Just pick one right?) And the reason I say “might” is because a lot of Scrum teams are starting to adopt the WIP limit technique too; it’s no longer exclusive to Kanban teams.
Another indicator that the second board is for a Kanban team is the use of a “Ready” state in the board flow. The Ready state indicates work that has met their Definition of Ready (DoR) and can be pulled into their board flow at any time as long as it will not exceed the WIP Limit for the next state. Scrum Teams work with their Product Owner to refine their user stories before committing to add them to the Iteration Backlog. We’ll talk more about that in the Ceremonies section.
One last indicator that the first board is for a Scrum team is the Iteration Backlog state. The Kanban team has a backlog but it’s pulled from when the team has capacity to do so; there’s no WIP Limit on the backlog because Kanban Teams LOVE work more than Scrum Teams – just kidding! I should also mention here that depending on the tools you use (electronic or not), what you see on the board states varies so be aware that the “concept” of a backlog and the visualization of it on your board may not be the same.
And, because I’m a coach who’s made a lot of mistakes and learned from them, I’d also like to encourage everyone that we (I’m talking to YOU managers and coaches, too) do not dictate what the board states should be called. The team determines the best way to describe the way work flows and should have ownership over the work states that make sense to them. I often coach teams to build their system with stickies and sharpies first so they can test it out before moving into a tool. Obviously for teams that are dispersed, that may be a bit more difficult but you’d be surprised how teams adapt. I was impressed by a team that set up a webcam for their Kanban board on the wall so that the testers in India could see it change realtime. They even had board buddies so that if the tester needed one of the cards moved, they could tell their buddy and they would move it for them.
Scrum Teams meet on the first day of every sprint to select, verify and commit to the user stories that will fit in their sprint based on the trends of their velocity (yes, we’ll talk about metrics next). Kanban teams don’t have Sprints, remember? So they don’t have this ceremony. They do sometimes need to plan though. What if the Kanban team is doing some work that another Scrum Team needs by Sprint 16? This is where the common sense comes in; you should not need a heavy process to tell you how to do this! First, they need to know about the work dependency in advance so that they know to pull that work item into their system with enough lead time to complete it before Sprint 16; so, yes, there is some planning needed. Think about scaling solutions and other human-to-human solutions here. I’ve also seen a lot of Kanban teams with an “intake owner” type of person that will meet with other teams, other Product Owners and managers to review new work and prioritize for the team. It can be extremely valuable to the team when work comes in from various channels and priority is not simply FIFO (first in first out).
Another ceremony that is technically not in Scrum but is often advised, is the Backlog Refinement (previously referred to as Backlog Grooming) session. Many teams need this time mid-sprint to review upcoming work, confirm they meet the DoR for the next or subsequent sprint and to size it so that the Product Owner can assess the cost (estimate) against the value; sometimes the work isn’t worth it now or ever. Kanban teams sometimes employ this technique too; so again, it’s not exclusive to a specific framework either. While Scrum Teams select a number of user stories that they believe will be started and finished within the boundaries of their Sprint, Kanban teams use the WIP Limits on their board to inform them when they have the capacity to pull more work into their system at any time.
Ah, metrics. The most loved and equally abused and sometimes hated thing we do to other people. Let’s face it, metrics can suck. I get it. But, if we want to get better, we have to know where we are now to know what “better” even looks like. So let’s have a data driven conversation. Ok? Ok.
If you look at the list of Scrum metrics, they are pretty simple. And it makes sense that they are. A single Scrum Team should be hyper focused on two things, getting shit done and getting it done at a sustainable pace so we can predict how much we’ll get done in the future. If we fail at either of these, we figure out why and try to change that. Once you’ve achieved both; have a party! Seriously, it’s an achievement that should not be underplayed. And once you’ve achieved both, share how you did it with others.
Kanban teams are not taught to size their work or task it out (yep, you heard me) and it’s not always necessary to do either. Think about the lean manufacturing history; they made the same things over and over again so the amount of variation was low. In software development, variation can be high so many Kanban teams still use the sizing and estimating techniques to relatively size their work and measure with more detail. But for a moment, let’s assume that they did not size or task. Then a Sprint Burndown and Velocity metrics don’t work for two reasons (think about that for a second). Now think again about a Kanban team that is sizing their work items; the two metrics still won’t work (Hint: no sprints). So, what do Kanban teams measure? Lead Time is the single most important metric for them. And, despite the inconsistent use of the word “Lead” time out there (another blog coming about that topic for sure!), Kanban teams need to customize the Lead Time metric based on what they are investigating through the use of specific work states and measurements. For example, we may want to measure the “Customer Lead Time” so that when they ask the infamous “When will I get it?” question, we will be able to tell them by including the time between when the request was made and when the solution was delivered to them. That calculation includes “wait” times not just the active “in progress” time we track once it’s pulled off the backlog. Customer Lead Time will be different than the “Development Lead Time” because we start the clock at a different work state in our workflow. Arguably, various Lead Time measurements could be used by Scrum Teams too and I believe they should. It’s an excellent way to gain understanding across the team about where delays occur in our system.
The second metrics is the Cumulative Flow Diagram. If you’ve ever seen one, it can be a bit hard to read properly but the intent is to see a steady flow of work progressing through the work states each day. At first glance, you might miss some key measurements that are embedded in the diagram. Looking closely at the graph, you’ll see a vertical measurement of the teams WIP each day (noting variance like slack and bottlenecks) and a horizontal measurement of how long it takes to get things done (Lead time). I find that using a ruler and sliding it across the graph to see the variation can help but it can be avery tedious manual process. If you have enough days worth of data, you can usually see the bottlenecks, slack and “weirdness” pretty easily without the ruler. Plus, there’s another fantastic metric that every team should use regardless of what work model they are using; Time in Process.
I cannot tell you how much I’m in love with this metric visually. The moment a co-worker offered it to me back in 2011, I was in love! Finally, I could see how often we got things done, how long it took and how big the work was in relation to the Lead Time. I could actually DO something with it instead of just looking at it and thinking “this is useless.” When metrics do that to you, seriously consider why the hell you are even measuring that anymore. Metrics should motivate you into action not bore you to death.
I’m often asked, “What type of teams use Kanban instead of Scrum?” There are a couple of things that stand out when choosing a framework; the type of work they do and how much planning they can do. A big marker I look for is about how and when the team’s backlog is filled. If the backlog comes from Project work, planned activities that are part of a larger portfolio of funded work; they are likely to choose Scrum because they can plan ahead for a majority, if not all, of the work on their backlog. If the backlog is mostly emerging work that happens without notice; the teams may benefit from a Kanban system. This is not, I repeat NOT, an excuse for poor planning. If the team is constantly reacting to last minute requests because someone is terrible at planning ahead (I’m looking at you Product Owners and Business people), that is not an excuse to “just use Kanban” so that Chicken Little can continue to create chaos for the team.
You may already be thinking that a lot of architectural, platform, higher environment testing and systems teams fit very nicely in Kanban. And you could be correct. These type of teams manage priority through Class of Service working agreements or simply a FIFO style backlog management. This is another reason they are able to operate without a Product Owner. They also appreciate not being forced to use Scrum and plan two weeks worth of work in advance during Sprint Planning. Servers don’t tell us they will be crashing at 3am in two weeks do they? No they do not… damn it.
Now you have some things to consider and talk with your team so they can collectively agree on which model suits the way they work. Having a team attend a formal training is a terrific starting point so that they understand the roles, ceremonies and artifacts that exist and build their working agreements together before their first day as a new Scrum or Kanban team. And remember that just because they have gone through training doesn’t mean they are experts right away. They will need coaching and reassurance to help them weave through daily events and challenges in doing work in new ways. Even the best NFL players still rely on coaches to help them make good choices and keep them performing at their best.