What is Best, Scrum or Kanban?

Page 1 of 7

Username

login

register

Did you forget your: Username / Password ?

Search...
i j k l m n Local n Web n Videos j k l m j k l m
HOME ARTICLES EVENTS BLOGS COMMUNITY MEDIA CENTER WHITEPAPERS RESOURCES JOBS AGILE CONNECT 2011

Home

> Articles

> Columns

> Articles

> What is Best, Scrum or Kanban?

We have 3881 guests and 19 members online

What is Best, Scrum or Kanban?

WRITTEN BY TOMAS BJRKHOLM SUNDAY, 07 JUNE 2009 21:58

56
tweets

retweet

I have for some time been thinking, what is best, Kanban or Scrum. I can't make up my mind so I decided to write an article in two parts, one where I wear the "I love Kanban" hat and one where I'm wearing an "I love Scrum" T-shirt. First I would like to tell you shortly what Scrum and Kanban is. Scrum in 1 minute Scrum is about getting back to the time when the company was small and everything was easy and ran smoothly. Back then projects were small, teams were small, releases were small and communication was easy. Best of all, we were efficient. In Scrum we split our big project into small projects as we work on timeboxed iterations called sprints. We split our big team into small teams (still with all the skills we need) and launch often. If we are more than 20 employees we probably have a problem knowing what the other departments and customers are needing so let's bring someone into the team that can represent them. To help communications from the team to the rest of the company we have our plan and current status visible. The plan is called the sprint backlog and the status is shown on the scrum board. Here is an example:

Agile Sponsors

HP

CollabNet TechWell

Featured Whitepapers
The Scrum Reference Card The Keys to Distributed and Agile Application Development Agile Transformation Strategy Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same One's Enough for Agile Application Development Management The person we brought in to represent all stakeholders is called product owner and is responsible for prioritizing a list with features that will be developed for the product in the future. This list is called the product backlog. To make Scrum a process we add some small but necessary meetings: a planning meeting, daily synchronizing meeting and meetings to improve product and process. We decide the length of our iterations and aim to deliver something valuable after each iteration.

Kanban in 1 minute Scrum is simple but Kanban is even simpler. Just visualizing your workflow and limiting demand to capacity is enough to call it Kanban. Let's start by looking at the roots of Kanban. It's a way, invented and used by Toyota, to get a good flow of parts to their plants. Kanban is just a card attached to the part and when the part is used the Kanban is sent as a request to the supplier for more parts. The physical card is actually sent to the supplier who is attaching it to the next pert sent. Since the cards are re-used and no new cards are entered in the circulation Toyota limits the number of parts in stock and at the same time make sure new parts are ordered as soon as they are needed.

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or... 2/29/2012

What is Best, Scrum or Kanban?

Page 2 of 7

In software development Kanban is a limited promise of work. A Kanban board is a number of placeholders for work to be done. A typical Kanban board can look like this.

Each team has decided their limit and drawn as many squares as the limit allows them to. Whenever a task is done it will be moved to the next group if and only if they have free Kanban squares. Else the task is stuck. If there is nothing more to do we have a problem with the flow and we need to work together to solve what is stopping us. While Scrum is focusing on delivering on commitment Kanban is focusing on getting a smooth flow. In common for Scrum and Kanban There are a lot of similarities between Scum and Kanban. Some examples are: A strict prioritization (it's obvious what to do next) Self-organizing teams (see below) Transparency (show what you've done, your current status and what's next to do) Inspect & adapt (improve your product and process based on facts) Pull scheduling (see below) Good communication and collaboration Self-organizing teams is when the team themselves are supposed to figure out how to solve problems, remove impediments and optimize their process. They should base their decisions on facts to inspect and adapt accordingly. Pull scheduling means the team is pulling work instead of having it pushed. This will limit work to capacity and lower stress, which is bad for both health and quality. This is why I prefer Scrum So, now that you know what Kanban and Scrum is, it's time to decide which is best.

I start by putting the Scrum T-shirt on. Look further down if you like to read the part where I love Kanban. I concentrate on some areas where Scrum and Kanban differ: Iterations - In Scrum you work in iterations. Kanban sees development as a forever ongoing flow of things to do. Commitment - In Scrum a team commits to what they will do during a sprint. Estimations - In Scrum you need to estimate to be able to have a velocity. In Kanban it's optional since focus is on timeto-market. Cross-functional teams - That's one of the pillars of Scrum. For Kanban it's optional. Efficiency driven by commitment By asking a team for a commitment they will get a positive stress knowing that people from outside will see if they can do what they committed to. It also gives an energy boost at the end of the sprint when the team has the goal within reachable distance. After the sprint, the team can feel relaxed and gather some new energy for the next sprint. It's psychologically nice to not feel you are in the middle of a never-ending stream of things to do. Instead Scrum concentrates on one sprint at a time and allows you to focus only on those things you have decided to take on in the sprint. By working in fixed length iteration you get a nice rhythm the whole company can feel and adapt to. The value of estimating Estimating is not a waste of time since valuable information is transferred from the product owner while the team asks what they need to know to be able to estimate. The same thing applies to commitment. To be able to commit team members need to know what they are committing to. They simply have more interest in getting information from the product owner so they listen more carefully. And they are just asking for the information they need which makes the meeting very efficient. Even though you can predict when a project is done, just by counting stories left, it is more precise if each story is estimated as well. Prediction is important when more departments, like marketing, are dependent on your work. It gives a more serious feeling. Slack at end of sprints If there are some time at the end of a sprint that's valuable even if the time is not big enough to start developing new features.

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or... 2/29/2012

What is Best, Scrum or Kanban?

Page 3 of 7

This is time developers can use to improve code quality or the development environment. Both will give better efficiency in the long run. Build teams with cross-functionality Working together in a cross-functional team is a psychological thing. You are able to go the whole way from concept to released product together as a team without dependencies. You are not just a cog in the machinery. It's also fun and helps you grow as a person. By helping each other, knowledge is spread which lessens dependencies on each person. It also helps prioritize since features can be built without considering which knowledge is available. To coordinate between people with the same skills who are sitting in different teams you can have virtual team meetings as often as needed. Scrum is best for beginners I know, you can do all those things even when doing Kanban but they are optional and since they are optional you might just not do them just because you are too lazy to challenge the usual procedures or structures of your company. If you are new to Agile development it's better to have a method guiding you to do the right things. Just read the book and implement it. Later when you get used to it you can start experimenting and eventually get better performance. If you start experimenting too early you might end up with waterfall or chaos but still calling it Agile. Kanban is more advanced because you need to make a lot of decisions without having many facts. This is why I prefer Kanban Now it's time to take off the Scrum-T-shirt and put on my "I love Kanban"-hat.

Kanban is based on Lean principles Kanban is Lean and has been around for 50 years and has shown to be successful. Things are seen as a flow without iterations. Not many rules. It's just a focus on reducing work in progress, strict prioritization and limiting demand after capacity. Besides that you have the normal Lean principles of: Quality Just-in-time (decisions and facts just when they are needed) Short lead-time (quickly from concept to cash), Kaizen (continuous improvement) Minimizing waste (everything that is not adding value to the customer) No meetings if it's not adding value to the customer. Most of those things are fine with Scrum but I can sometimes think Scrum has some waste. Here I will mention some areas where Scrum practices might be waste. Estimations might be waste If a product owner knows what needs to be done and the only goal is to have it done as soon as possible, why spend time on estimating? In Scrum, estimations are needed for a team to know how much to commit, to calculate velocity and for the product owner to decide on prioritization. If none of this is needed, it's waste and we shouldn't do it. If you like to measure velocity you can instead count the number of stories done per week or month. While talking about measurement why not look at something the customers are interested in, lead-time. That is, the time it takes for the customer to get what he or she ordered. Constant flow If the team is done with a story and there is not enough time left in the sprint to complete the next, it's likely no one works hard the remaining time and that's waste. Kanban is trying to get a steady and non-stressed but high flow of work running through development. Sitting with people that can help you In Scrum a team is cross-functional and sits together with the people working with the same project and not with the ones with the same knowledge. Let's say you work with sound effects for a computer game. Then it's not much help to have a javaprogrammer beside you. It would be more valuable to sit with people doing the same things as you do who can help you with tools and practices. No possibility to commit In Scrum, the team commits which does not work very well for a team with support issues. They get a lot of disturbance and commitment is not worth anything since the ones disturbing them don't care about commitment. A commitment you can't control gives either frustration and stress or demotivation. Kanban for support and operation teams Support and operation teams are often interrupted. It's part of their job. Frustration comes when interruptions are happening just because there were no time for pre-emptive work. Just by having the pre-emptive work on the board gives focus to fix the hardest problems one-by-one, which gives less interruptions and more time to work pre-emptively. It becomes a good circle. A Kanban board for an operation team can look like this:

Most important are the urgent problems that arise. Secondly, daily duties must be done. Then the team members can take care of other projects, usually to improve stability in the operation environment. The limitation on the number of parallel tasks gives

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or... 2/29/2012

What is Best, Scrum or Kanban?

Page 4 of 7

focus to be done working on improvements, not just starting them. Many options gives freedom Kanban is simple with few constraints, which gives you freedom to change your process step by step. Either you go from waterfall or chaos, your first step is to visualize and limit your flow with a Kanban board. When you have your flow visualized you add whatever work is needed to thrill your customers. Your improvements might be decided during a monthly retrospective meeting or on a daily meeting. Conclusion I still can't make up my mind if I like Kanban or Scrum the most. My conclusion is, not very surprisingly, that it depends on the situation. See them as two different tools and find out which tool is the best for your situation. Maybe you start with Kanban and end up with Scrum or maybe you don't. Maybe you'll start with Scrum but change to something more like Kanban. Whatever you do, just make sure you do what is best for your customers.

About the Author Tomas Bjrkholm is living in Stockholm, Sweden. He's working at Crisp where he is helping companies becoming efficient by implementing Agile and Lean. Some of the pictures are made by Henrik Kniberg at Crisp. Thanks for letting me use them.

Hits: 57435

Email this

Bookmark

Set as favorite

Trackback(0)
TrackBack URI for this entry

Comments (19)
...
WRITTEN BY CHRISTIAN PENDLETON, MAY 09, 2011

Nice article with a objective view of them both. I agree that Kanban requires a more mature team than Scrum to work since there are fewer procedures built in the process. Procedures are IMHO valuable when you start working with a new process to get it "up and running". As time goes and everyone in the team/organization starts to understand more fundamentals of the process, you get the freedom to experiment more and more with the procedures to get your own optimized way of working. There are a few procedures in Scrum that I think you should think about when going for Kanban. I will bring up two of them here: One is the sprint demo. The demo is obviously a very team boosting activity and when using Kanban, it is easy to neglect this team boost. It really does not have to be very hard. A team that I coached in the use of Kanban, we simply took 15 minutes every Monday and read through all the tasks we had fulfilled the previous week. It gave us a good feeling of creating value. The other is the sprint planning. To sit down as a team, discuss the stories and/or tasks and make the estimate is good for spreading the knowledge about the backlog in the team even to those members that does not look at the backlog between the planning sessions. In the same team as above, we solved it by scheduling a session every monday where we as a team read through the backlog together with the PO, adjusted priorities and added tasks that spawned when reading the other ones. Prio adjustments could then be done whenever during the week, but we had a good base.
+0

...
WRITTEN BY MARIO MOREIRA, JANUARY 05, 2011

Is "it depends" an answer? Both are great tools in the tool kit. Kanban tends to work better (for me) with short delivery cycles and Scrum works better for longer delivery cycles where the sprint cadence has benefits. So the winner is...
+17

...
WRITTEN BY ALEX TRAN, NOVEMBER 21, 2010

Very good review.

+0

...
WRITTEN BY TERENCE F, NOVEMBER 19, 2010

Sorry, missed the link code in previous post: Scrum vs. Kanban on OutSystems Blog
+1

...
WRITTEN BY TERENCE F, NOVEMBER 19, 2010

I just read a more recent blog post on this very topic. Here is the link in case you are interested. http://blog.outsystems.com/aboutagility/2010/11/scrum-vs-kanban.html
+0

...
WRITTEN BY VALERIA KOKINA, NOVEMBER 17, 2010

Although I haven't huge experience in Scrum and Kanban, I use their in my ordinary work day. I think, that Kanban board is very good for selfmanaging or working with 1 or 2 subordinates. More subordinates, more tasks, cards... It becomes uncomfortable. The efficiency of Team decreases. Scrum is much helpful when we speak about team. It helps to motivate the each member of team. Most of all I like in Scrum, daily Scrum meetings (great mean of selfmotivation) and Planning Poker (it is really simplier to make decisions with it). To sum up, I believe that Scrum is better for teams of more than 4-5 members while Kanban is better to use in smaller teams.
+2

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or... 2/29/2012

What is Best, Scrum or Kanban?

Page 5 of 7

...
WRITTEN BY NADIA ROMANO, OCTOBER 25, 2010

May a suggest an article that describes three ways to go beyond Scrum http://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=scrum
+0

...
WRITTEN BY TOM, JANUARY 27, 2010

I agree with Josh-why not to use both Scrum and Kanban and get advantages of both? Many tools support this approach, for example http://kanbantool.com
+1

...
WRITTEN BY UDAYAN BANERJEE, SEPTEMBER 09, 2009

Though I am a strong believer in agile methodologies (I am not partial to either Scrum or Kanban), there is one aspect which have always disturbed me. I have highlighted that in this post "Why am I uncomfortable with product backlog" http://setandbma.wordpress.com...t-backlog/ Any thoughts are welcome.
-3

...
WRITTEN BY JOSH MILANE, SEPTEMBER 09, 2009

Can't we un-productize and un-brand everything and just see this stuff for what it is? Dennis, yes they can exist at once... and that can be a great experience. But that's not the question I don't think - the question is about your team's readiness and preference towards the techniques and features in both. It is like cooking... you have Asian and Mexican and then this thing called Asian Mexican fusion. Imagine just having Mexican and Asian ingredients. You would just be cooking. Thanks, and sorry if this is a dupe post. I have a jumpy finger. Best, Josh www.mittechnical.com/blog josh@mittechnical.com
+1

...
WRITTEN BY JOSH MILANE, SEPTEMBER 09, 2009

I would conjecture (with a little more than a guess behind it) that you can actually use both Kanban and Scrum at the same time. Since every flavor of Agile is being productized to death, I'd like to see all these concepts scooped up, stripped of their names, and shaken in a box. That box would be useful. Thanks, Josh www.mittechnical.com/blog josh@mittechnical.com
+4

...
WRITTEN BY CHRIS HEFLEY, SEPTEMBER 09, 2009

Well said. And speaking of tools, we're currently beta testing our new online Kanban tool: http://justkanban.com. Though, even if you're wearing your "I Love Scrum" t-shirt, the visualization benefits of an online board like ours can also be very useful. We'd love for your readers to sign up for the beta program. It's currently a "private" beta, so you won't get your account immediately, but we're passing new accounts at the rate of about 20/day right now. You can also follow us on twitter as @JustKanban. Thanks!
+0

...
WRITTEN BY JOHN CLIFFORD, JUNE 15, 2009

I'm agnostic when it comes to believing there's only One True Way, instead preferring the 'toolbox' concept where I can pick and choose best practices. Scrum versus Kanban doesn't have to be either-or... it can be both. There's no reason why Scrum and Kanban can't coexist in an organization, or even at the team level. One good way to increase sprint team productivity is to run Kanban inside of Scrum, i.e., track tasks in the sprint via a Kanban board, with assigned WIP limits for each functional specialty (design, code, test, etc.). Doing this can help spot constraints within the team that impede velocity. Kanban inside Scrum makes recognizing impediments easier by lack of movement of an item between workflow stages. For instance, if items are coded quickly but not tested quickly, perhaps more emphasis needs to be put on testing. Look at Corey Ladas' website, http://leansoftwareengineering.com, for some ideas on using Kanban inside Scrum. I've used both Scrum and Kanban and find both to be effective. I don't understand the comment about how a team can't commit with Kanban; the team has to commit to doing each discrete transformation/process step as quickly as possible to the definition of 'done.' As with Scrum (and any other process), you have to have people who are motivated to do the work, someone who owns driving impediments to resolution, someone who owns prioritizing the work items, and someone who is responsible for team ROI... and people can play multiple roles in Kanban. Cumulative flow diagrams show how items age in each 'silo' and if there is no movement then something is not working. Kanban, like Scrum, encourages team selfmanagement; the team is expected to recognize and then 'swarm' to solve impediments.
+3

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or... 2/29/2012

What is Best, Scrum or Kanban?

Page 6 of 7

...
WRITTEN BY JANI V, JUNE 11, 2009

Thanks for the good article. Although, I could argue that is there even a need to create 'a battle' between Scrum and Kanban. There is place for everything, depending on time and place, as you also stated as a conclusion. This might be off topic a bit, but it is one interesting area inclining your topic of how different methodologies fit and where. In my work I face some methodology and process battles, which I see are somewhat unnecessary. Questions like, is this Scrum, is this Agile etc. are almost daily. It is good when people question, but if it is done all the time, I see it is taking energy away on doing the real stuff, like improving work practices. One of the biggest reasons for misunderstandings in this specific matter is, that people mix a lot team processes and methodologies to organizational level processes. To simplify my argument, Scrum is team process and organization level processes are more lean production processes, therefore the practices differ. As an example, I could give burndown or velocity chart; for individual team it is really useful, but company level more interesting is value for the business and is it increasing or not. The larger the scale, more information links exists and to be honest, pure Scrum itself doesn't fit well in organization level as such. Those principles and processes come from lean production more.
+3

...
WRITTEN BY ERIK LUNDH, JUNE 11, 2009

Well, The many teams that I have coached through the years has been sucessfully applying kanban priciples in the agile planning since the fall of 2000. I first learned about kanban while working with justin-in-time industry automation in the mid 1980s. We originally augmented the XP Planning Game with some Kanban thoughts. But not like Anderson or even Mary P think is best, by having sharp limits on the size of the "inbasket" to the agile team. "Not my problem" is a agile smell, not an agile sucess factor. We, in a sense, apply the constraint of quesize for the current iteration, but keep the conversation open on upcoming iterations, to get the feedback loop benefits and keep distilling what is the most important in the coming iterations. Just cutting off input dumbs down the whole process. There are other problems with Scrum that has made Swedens largest software development organsation with 10s of thousands of developers avoid Scrum adoption in the large. There are of course local initiatives by the usual suspects, the consultancy house who want to make an easy buck on Scrum by anyone available, and the trainers always looking to offer another McCourse. But the terminology of Scrum triggers all kinds of dysfunctions in midlevel managers, and to introduce the ScrumMaster role would nullify the Highperfomance Team Environment research and implementation that this organisation has done sine mid-90s. The bets teams act as a person and does not need a spokesperson. (I know that is not what a CSM is supposed to do, but I observere emergent behaviour, regardless of good intentions) Interestingly enough, NOKIA, one of the Scrum franchise poster cases move in a similar diretcion, even though they are heavily entreched with Scrum terminology and Scrum franchisee's.
-2

...
WRITTEN BY TORROID, JUNE 10, 2009

Seems to me this much argument about Scrum or Kanban isn't Agile and Lean to begin with.
+0

...
WRITTEN BY DENNIS STEVENS, JUNE 10, 2009

Nice post. In you mind, are Scrum and Kanban mutually exclusive? Could I use Kanban outside (upstream and downstream) of the development team and have development as a single work center on the Kanban board doing Scrum/XP practices?
+1

...
WRITTEN BY MATTHIAS MARSCHALL (@WEBOPS), JUNE 10, 2009

We came from a more Scrum like process but more and more evolved it into something closer to Kanban. Read the whole story at: http://www.agileweboperations.com/agile-quo-vadis/
+1

...
WRITTEN BY LARRY MACCHERONE, JUNE 10, 2009

Great article. I especially like the 1 minute descriptions.

+1

Write comment
Show/hide comment form

Name

Comment

6
smaller | bigger

b c d e f g Subscribe via email (registered users only)

Write the displayed characters

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or... 2/29/2012

What is Best, Scrum or Kanban?

Page 7 of 7

Add Comment

Preview

Like

4 people like this.

LAST UPDATED ON TUESDAY, 23 JUNE 2009 18:05

Agile Marketplace - Announcements and Special Offers

Upcoming Webcasts Sponsored by Urbancode - On Demand Mastering Complex Application Deployment Sponsored by CollabNet - Wednesday, August 24, 2011 Closing the Agile Loop: Continuous Integration, Continuous Information ScrumWorks Pro The Worlds Best Agile Project Management Tool Simply put, CollabNets ScrumWorks Pro is the best Agile project management solution on the market, bar none. More than 150,000 Agile professionals rely on the power and simplicity of ScrumWorks every day. But dont take our word for it try it yourself for free. CollabNet is now providing the first 10 users of ScrumWorks Pro at no charge! Download ScrumWorks Pro today! The Business Case for ALM Transformation Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change. Download this Whitepaper

Most Popular Articles

What is Best, Scrum or Kanban? Go For The Low Hanging Fruit! Register Now for Agile Connect 2011 AgileEVM Earned Value Management The Agile Way Agile Connect 2011 Building a Relationship with Agile Scaling Agile Development Via Architecture

Industry News
PRESS RELEASE: Affymetrix Chooses Original Software to Support its Centre of Excellence for Software Testing PRESS RELEASE: SmartBear Software Announces Code Collaborator 7.0 Skytap and Customer Invited to Speak at Leading Technology Conferences Rally Software Supports PMI Certification Program for Agile Project Managers TestRail Hosted Edition Announced Reflective Solutions sign Partnership Agreement with Capgemini UK

Copyright 2006 - 2011 CMC Media, Inc. All rights reserved. All marks are trademarks of CMC Media Reproduction in whole or in part in any form or medium without the express written permission of CMC Media, Inc. is prohibited. Agile Journal, Agile Business and AgileWiki are trademarks of CMC Media.

Home | Articles | Login | Blogs | Webcasts | Resources | Forums | Media Center | About Us | Contact Us | Privacy Policy | CM Crossroads

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or... 2/29/2012