raaphorstWhen inflexible and wasteful software development processes are making your organization inefficient, it’s time to introduce an agile methodology. Kanban vs Scrum then becomes an essential question: Which agile software development methodology is better suited for my own situation? And is Kanban agile? What about Scrum vs agile? Confusion is spreading… Let’s have a look how to sort out all those questions.
Scrum – A Fundamental Shift
Scrum is a well-defined process framework for structuring your work. Introducing Scrum is quite a change for a team not used to agile software development: They have to start working in iterations, build cross-functional teams, appoint a product owner and a Scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits of the Scrum methodology are well understood: Less superfluous specifications and fewer handovers due to cross-functional teams and more flexibility in roadmap planning due to short sprints. Switching your organization to use Scrum is a fundamental shift which will shake up old habits and transform them into more effective ones.
Scrum Leverages Commitment As Change Agent
The initial introduction of Scrum is not an end in itself. Working with Scrum you want to change your teams’ habits: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motiviated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.
Kanban – Incremental Improvements
The Kanban methodology is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum 😉 ). In Kanban, you organize your work on a Kanban board. The board has states as columns, which every work item passes through – from left to right. You pull your work items along through the in progress, testing, ready for release, and released columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. By managing WIP you can optimize flow of work items. Besides visualizing work on a Kanban board and monitoring WIP, nothing else needs to be changed to get started with Kanban.
Kanban Leverages Work In Progress (WIP) Limits as Change Agent
For every column (state) on your Kanban board you should define a “Work In Progress”-Limit (WIP Limit). The WIP limit tells you how much work items are allowed to be in a certain state at any given point in time. If a state reaches its pre-defined WIP limit, no new work can enter that state. The whole team has to help clear the filled up state first. Work items trapped in a state will build highly visible clusters on the Kanban board. These clusters make bottlenecks in the progress visible – you can simply look at the Kanban Board to see where your process needs improvements. Making the need for improvement visible challenges your team to change the way they work to avoid such bottlenecks in the future. That’s how WIP limit act as change agent in Kanban.
Kanban vs Scrum
Looking at both agile software development methodologies it should be more clear what to introduce when: If your organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum seems to be more appropiate. If you already have working processes, which you want to improve over time without shaking up the whole system, Kanban should be your tool of choice.
And Scrum vs Agile?
Asking for the differences between Scrum vs Agile or Agile vs Scrum is like asking for the differences between “Water” and “Ice”. Ice is water in a specific physical state. The same could be said about Scrum vs Agile. Scrum is agile in a specific shaping. It is an agile process framework. Scrum and Kanban in software development are both specific shapings of an agile software methodology. While Scrum vs Kanban or Kanban vs Scrum is comparing two agile methodologies, Scrum vs Agile is comparing a concrete example with its fundamental principles.
Agile Web Operations 
Matthias, that does simplify things very nicely. Thanks for the overview.
One very visible and notable difference is that Scrum has the Sprint Planning meeting and the Spring Retrospective. They demand customer involvement in a very pointed way. It’s rather easy for the customer to ignore “the board” with the attitude that it’s just for the geeks to play with. The customer really can’t ignore Scrum because it starts and ends with the customer.
LikeLike
Mark, thanks for pointing this out. It’s a good example showing that Kanban is not a process framework like Scrum. Exactly such things like customer involvement (and many more) have to be defined separately. It’s even a good idea to run Scrum and improve it over time using Kanban (sometimes this is called “Scrumban”)
LikeLike
Matthias,
a very nice and interesting summary. The introduction of Kanban to our company worked smoothly and the result has been efficent as expected. There was no change management needed as this is easy to implement and to understand with an immediately outcome of results. Have you also some more experience and some advise how to efficiently upgrade from Kanban to Scum (Kanbum?)?
LikeLike
Hi Matthias,
Enjoyed reading this summary of Scrum and Kanban. It’s nice to see concise well written paragraphs.
Wanted to point out though that Kanban is a pull system versus a push system, instead of, “You start left with the Backlog, and push your work items along through the in progress”, it should read, “You start on the right hand side of the board and pull work items through based on the allocated capacity”.
Thanks!
Dominica DeGrandis
LikeLike
that is actually a great way to put it! Hadn´t think of a such nicelly way to explain the difference in the mindset
LikeLike
Yes, this is the core of Kanban concept. Very well put. We do not push but pull. 👍🏻👍🏻👍🏻
LikeLike
This is several years later, but your description of Kanban as a pull system really resonated with me. Thank you very much!
LikeLike
Thanks a lot Dominica for pointing this out. Of course, you’re absolutely right. I fixed it (I hope).
LikeLike
Hi Matthias,
I have published a similar post before, “Scrum to Kanban“. The post lists the flaws in Scrum, and then talks about Kanban and how to migrate from Scrum to Kanban.
I think your article is excellent as a comparison between the two, and I would like to republish it on PM Hut. Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.
LikeLike
As you also pointed out “to SCRUM or to Kanban” is for me presenting in essence a false choice. The real driver for performance is not what framework you use, it’s what work management principles you choose to believe in and how those effect your implementation of any framework.
In the end SCRUM or Kanban are just frameworks or ‘systems’, you can use them in any way depending mainly on the underlying values and principles of management (linked to your company’s management culture). So rather then making it a choice between 2 frameworks I rather start a discussion on management values and principles as those are the real drives of a team/organisation performance.
Conventional management values / believes in mostly:
Economies of Scale
Resource specialisation
Resource utilisation
Micro manage workers
Control activities
Perfect thinkers doers
Up front design
Fixed price scope time
Cost accounting
There are 2 main categories of modern values and principles:
1. Agile values and principles > which focus mainly on business value (build what brings value to your customers)
2. Lean values and principles> which focus mainly on flow (produce more faster)
If an organisation is serious about it’s transformation you need both to get what I call ValueFlow, it’s a single noun (bit like SpaceTime) because they are intrinsically linked.
I am over simplifying here but its fair to say that SCRUM is mostly about being Agile and Kanban mostly about flow, meaning that
– a strict implementation of SCRUM only will not lead a maximum value
– a strict implementation of Kanban only will not lead to a maximum flow
In practice there are many constraints linked to changing things on the work floor to increase both value and flow. The main one is the current set of values and principles valued by management and how easy/difficult it is to change them.
Scenario1. In general: If your company culture is very conventional and not open to change it’s management culture I would start with SCRUM with the intention to let it evolve by incorporating Lean Kanban elements. SCRUM is easier to sell and roll out in many organizations because its closer to their current way of managing things so you might get more support for SCRUM leading to faster success. There is an exception though, SCRUM will not work for all teams and will be contra productive, the main question to ask for a specific team is: can you plan 2/3/4 weeks ahead? If no don’t apply SCRUM but directly go for Lean Kanban.
Scenario2. If you can get management to be aware of the need for valueflow and they are open to the Lean Kanban management principles I would implement a Lean Kanban system combined with certain Agile value based principles and techniques (like impact mapping, story mapping). I personally believe that a lean kanban system combined with the right agile principles and techniques can provide more valueflow than a time boxed scrum system using some lean kanban principles but it requires a bigger change in management culture, a willingness to let go of old habits. Reason for my opinion is that increasingly service based companies need to keep up with the fast changing world of the post-millenials and planning / time boxing becomes more and more difficult.
Let’s take scenario 1 further as this would apply to most cases. In my experience I see things evolving further in 2 directions:
1. SCRUM slowly (or in some case very fast) sliding back to waterfall behavior because of the overpowering influence of the conventional management principles.
2. I see more mature teams automatically look at/move to lean kanban principles (visualizing wokflow, letting go of the timeboxing).
Above I was talking mostly about how the company culture define the performance of a SCRUM or Kanban implementation (remember culture eats strategy for breakfast P. Drucker.) However the use of SCRUM or Kanban also have an impact on the culture (Culture follows structure). In my opinion Lean Kanban is structuring the work that changes an organisation to more modern management practices based on flow whereas SCRUM is structuring the work in a way that reinforces the conventional management culture (very easy to slide into waterfall pitfalls).
LikeLike
I am a strong champion of Kanban over Scrum. I believe that organization will soon realize the importance of Kanban over Scrum. With my professional experience, why I can say that the why Kanban has an edge over Scrum because of:
1) In Kanban, we imposed a WIP (Work Limit), thus if a team member is stuck in some functionality or there exist a bottleneck. It can be identified straight away and its visible to whole team as each task or User Story is always track on board.
2) In Kanban we don’t have a release schedule unlike in Scrum where we planned for 2 weeks – 4 weeks releases. Thus, in Kanban, each time even if a single User Story is developed and validated. Its ready to be pulled into the Production environment by the Business Stake holders/Management. However, it can only be achieved if company has CI process in place.
LikeLike
The purpose of WIP is for 2 reasons
1. To keep the team focussed on limited work items and hence to be efficient
2. To let the team re-organize within themselves when WIP limit reached / any bottlenecks
However in scrum, it is part of team’s basic characteristics to be self organized within a sprint to meet the commitment. The WIP for scrum team is sprint commitment.
There are matured teams who deliver to production every 1 hour in real time with Scrum too. It all depends on business requirements & demand, if there is a need to release software everyday, then the sprint duration in Scrum would be a day.
LikeLike
I’d say complexity is a factor in how you manage the workflow. For a simple process, kanban offers a clear benefit to maximize FIFO workflow while avoiding rework and delays that often come with batching. However, if you are talking about a cross functional process where several tasks are completed in parallel where dependencies exist between tasks, it might be easier on the team to work in Sprints, as selecting which task to work on next will be a more difficult decision.
LikeLike
Great Article. Thank you.
LikeLike
Kanban seems to be very close to waterfall method. Not sure why it has agile appended to it.
LikeLike
While you can define “phases”, which look like Waterfall on first sight, Kanban focuses on continuous flow. Instead of finishing everything in one phase and only then moving on into the next phase like in waterfall, you try to move each and every individual ticket through the stages as fast as possible. Each ticket creates value on its own as soon as it is done. That’s in stark contrast to Waterfall where you only create value once you moved all tickets through the stages.
LikeLike
Precise and to the point. Thank you!
LikeLike
I believe both methodologies are good to implement based on the culture of the organization. If you have a new team or If you are new to the team , to get to know about the team it is always better to implement scrum. It helps you to understand the strength of the resources. Once you set the right team based on skill set and potential, you can move to Kanban.
I liked the clear and crisp explanation of the differences.
LikeLike
About two years ago I came to an interesting conclusion — it doesn’t matter how you call it as long as you apply the right principles.
You can read more about why here:
View at Medium.com
LikeLike
Good explanation for Agile practices (as i understood) Scrum and Kanban. Thank you very much for that.We’re moving to Kanban from Scrum and your article helped me understand a fair deal of Kanban.
I think it’s more about the state of “WIP” in Kanban where i can see where exactly the bottleneck is and work on it even if the entire team needs to be on same thing to remove that blocker.
One doubt if you can please help me with, all of the agile ceremonies (like an Iteration, kickoffs, stand ups or retrospectives) will still apply the same way to Kanban as they were used in Scrum ? I should still break a bigger chunk of story in the smaller pieces as it’s another form of Agile ?
In an actual working environment, we used to start many stories at the start of iteration having multiple people (SDs, developers and testers) for each and then those stories will progress in parallel having the same start and ending dates. Now i can say there won’t be starting point if i understood correctly your explanation, and at first we will put as many people as possible or as required to finish that story without a predefined finishing date and then take up another story. Some of the stories may be running in parallel but they will be independent of starting dates and ending dates i.e no common start and ending dates in other words iteration start and end dates.
LikeLike
I really love the metaphor ice-water, scrum-agile. Gonna use it often 🙂
LikeLike
It’s actually the other way around.. scrum sprint is more like mini waterfall, which eventually turn into one big one.
LikeLike