Kanban vs Scrum: Kanban isn’t for Software Development, but Scrum is!

There are a number of software teams and organizations that think they should choose between Kanban and Scrum as their software development process.  This is a GIANT and RISKY mistake, in my professional opinion.

It’s not an either/or proposition.  Scrum is about software development.  Kanban is about change management.

There are several reasons why choosing Kanban as your team’s software development process is a mistake.

1.  You are applying Kanban to the incorrect context.

Would you use a hammer to insert a screw in a wall?  You can, but you’ll probably damage your wall in the process, and the same is true of Kanban as a software development approach.  David Anderson, the creator of The Kanban Method, has apparently said this over and over again since 2005, but no one seems to listen.

Don’t take my word for it, listen to David:

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!” — David Anderson

“There is no kanban process for software development. At least I am not aware of one. I have never published one.”  — David Anderson

“It is actually not possible to develop with only Kanban.  The Kanban Method by itself does not contain practices sufficient to do product development.” — David Anderson*

(*The first two came from the “over and over..” link above.  The last quote was sent to me via email from someone at David’s company.  I think they just pasted in something David had already written)

I should also mention that others have mentioned to me that David talks out of both sides of his mouth about Kanban, Agile, and software development, perhaps trying to capitalize on the fame and success of Agile software development.  That may be true, but it may also be true that David has been saying all of these things for years and no one is paying attention to what he says, which is unfortunate.

2.  Kanban is modeled more after the assembly line and manufacturing.  Scrum is modeled more after creative product design.

Which do you think more closely resembles software development?  Laverne and Shirley on the assembly line at the Shotz Brewery? Or the group of NASA engineers on the ground who saved the lives of the Apollo 13 astronauts by coming up with a creative solution to a problem within a time-box?  If you think software rolls off of an assembly line, then I think that it is unfortunate that you’ve never worked in a creative software development environment — it’s AWESOME!

Maybe my Laverne and Shirley reference is oversimplified.  The reason to use Scrum instead of Kanban for software development delves down into process control theory, and the difference between a “defined process” and an “empirical process.”  In short, a defined process works better when the inputs and outputs to the process are well known and repeatable (like a manufacturing line).  An empirical process works better when the inputs and outputs to the process are less known and very difficult to repeat.  No two software features are alike.  This is why it’s darned near impossible to measure software productivity directly, even though some naive “bean counters” still try to.  Like the stock market, no one metric will predict it accurately, but a range of indicators can help predict it more accurately.  So, in summary, Scrum is based on empirical processes like product design.

One of the very key parts of empirical processes is the characteristic of inspecting and adapting the product.  Think of yourself making a pot of soup from scratch, without a recipe.  Think about all of the “taste-tweak ingredients-taste” experiments(feedback loops) you would need to get a pot of soup that tastes good.

Scrum has the frequent feedback loops built in, for a variety of audiences(Dev Team, Product Owner, Stakeholders, Users) , and for a variety of topics(process-Sprint Retro, product-Ordered Product Backlog, product-Sprint Review, product-Valuable/Releasable Increments).  Kanban has no such built in loops, but again, that’s because it wasn’t designed for software development!

3.  From a Complexity Science view, Kanban is for ‘complicated’ work while Scrum is for “complex” work.

I know the Kanban folks don’t like hearing this, but I think Ken Schwaber was right when he said this, and I think history will prove him right about Kanban as it was described in David Anderson’s book.  In short, the Cynefin model defines 5 domains, of which 2 of them are “complicated” and “complex” work.

‘Complicated’ work is best solved via ‘good practice’ and ‘experts’ who can find ’cause and effect’ fairly easily. When I think of ‘complicated’ work, I think of an the IT support person who sets up your computer or trouble shoots it.  Yes, you need an expert to solve these problems, and the vast majority of the time, the steps to solve these kinds of problems are fairly consistent and repeatable.  They are not exactlyrepeatable, just mostly repeatable.   If the steps were exactly repeatable then they would fall into the ‘Simple’ domain of Cynefin.

‘Complex’ work is best solved via ‘safe to fail experiments’ and one can only ascertain cause and effect after the fact.  Each Sprint in Scrum is a ‘safe to fail’ experiment because, while the Sprint increment is always releasable, the business side of the house makes the decision on whether it is safe/valuable to release it or not.  In the case of an increment that is un-safe, the team course corrects and comes back with an increment the next sprint that is hopefully safe or more-safe.  These safe to fail experiments can be repeated over and over again until it’s time to release the increment.

Applying Kanban Correctly

Having said all of the above, there IS a time and place for Kanban — a correct context, if you will.  If you’ve been reading closely, that context is as a change management process, which is ‘complicated’ work, and requires that there be already existing processes in place.  So, if your software team is doing XP, Scrum, Crystal, Waterfall, RUP, DSDM, FDD, etc, then you can layer Kanban on top of it to help find bottlenecks and waste.  Also, for all of those teams out there that don’t use a software development process(framework, approach, etc) that is named in the industry, you’re probably doing cowboy coding, ad-hoc, or command and control project management — none of which is a software development process either.  So, layering Kanban on top of crap will still yield crap.

For those that want to apply Kanban at the enterprise level to monitor the flow of work through their Scrum teams (Or XP, Crystal, etc), or want to use it for IT support or Dev Ops, I say have at it and I hope it helps you.  I imagine just visualizing your workflow alone will help in those contexts.  I myself have recommended and coached Kanban for a couple of teams — but only because those teams exhibited the right context for Kanban to be successful.

Having said all of this, just visualizing your workflow and the other Kanban principles is not enough for software development.  Software development has things like business value, technical complexity, and user experience/acceptance/adoption — all of which are not addressed directly by Kanban.  Scrum does address these areas, as I have shown above.  But hey, let’s not forget, the Kanban Method is “not a way of making software or running projects that make software.”  Would you criticize a hammer for not doing a good job of being able to insert a screw into a wall?

Methodologies: Agile vs Scrum

Due to increasingly rapid rates of change in the corporate world, whether they occur within customer demands, project requirements, support issues or tasks, many companies are finding that their traditional business processes do not allow them to move fast enough and keep up with changes.

An increasing number of project management, product management and software development teams are transitioning from traditional Waterfall methodologies to Agile ones. Those who are new to Agile are often unaware of the fact that there are different types of Agile methodologies. One of the most popular Agile process is the Scrum methodology. We hope that this post clarifies the idea behind both Scrum and Agile.

An overview of the Agile methodology

The Agile methodology was first introduced in 2001 when the “Agile Manifesto” was formalized when 17 people got together at Snowbird Ski Resort in Utah. The Agile Manifesto outlines 12 important principles, which include communication, collaboration, the importance of software, and open-mindedness to change.

I previously wrote a post entitled Waterfall vs. Agile, in which I explain what differentiates Agile from Waterfall. The Agile methodology was basically put together as a solution to circumvent to pitfalls associated with Waterfall. Being a more flexible management framework, Agile allows teams to bypass traditional sequential paradigms and get more work done in a shorter time period.

What new Agile teams don’t realize, is that there are different types of Agile methodologies, the most popular one being Scrum.

The Scrum Methodology

Most teams that transition to Agile choose to start with Scrum because it is simple and allows for a lot of flexibility.

As explained on Scrummethodology.com, “Scrum is unique because it introduced the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases.”

What differentiates Scrum from other methodologies?

– Scrum has three roles: Product owner, team members, scrum master.

– Projects are divided into sprints, which typically last one, two or three weeks.

– At the end of each sprint, all stakeholders meet to assess the progress and plan its next steps.

– The advantage of scrum is that a project’s direction to be adjusted based on completed work, not on speculation or predictions.

The Scrum process includes the following steps:

Backlog refinement

This process allows all team members to share thoughts and concerns, and properly understand the workflow.

Sprint planning

Every iteration starts with a sprint planning meeting. The product owner holds a conversation with the team and decides which stories are highest in priority, and which ones they will tackle first. Stories are added to the sprint backlog, and the team then breaks down the stories and turn them into tasks.

Daily Scrum

The daily scrum is also known as the daily standup meeting. This serves to tighten communication and ensure that the entire team is on the same page. Each member goes through what they have done since the last standup, what they plan to work on before the next one, and outline any obstacles.

Sprint review meeting

At the end of a sprint, the team presents their work to the product owner. The product owner goes through the sprint backlog and either accepts or rejects the work. All uncompleted stories are rejected by the product owner.

Sprint retrospective meeting

Finally, after a sprint, the scrum master meets with the team for a retrospective meeting. They go over what went well, what did not, and what can be improved in the next sprint. The product owner is also present, and will listen to the team lay out the good and bad aspects of the sprint. This process allows the entire team to focus on its overall performance and identify strategies for improvement. It is crucial as the ScrumMaster can observe common impediments and work to resolve them.

Redmine Scrum Plugins

Scrum and Kanban Plugins for Redmine

Redmine is a popular open source project management web application. It was written using the Ruby on Rails framework. This software is more oriented towards a traditional approach for project management with Gantt charts and calendar than Agile, Scrum or Kanban. However, Redmine architecture allows however creating plugins to add additional features. The development of a number of Agile and Lean plugins has therefore been started in these past years. However not all those plugins have been in continuous development until the current release of Redmine 1.2.1.

You will find below a list of Scrum and Kanban plugins that you could consider to use. You might also decide to fork some of the “abandoned” projects if you are willing to put them up to date. The number of these plugins is limited and trying to add Scrum/Kanban support to Redmine might not be the easier road for your Agile open source journey. For people that are looking for open source solutions, the Open Source Scrum Tools Directory is a good place to visit to have an idea of available open source Scrum tools.

Active Plugins

* Easy Agile

Easy Agile is a simple task board that allows you to define stories and track their statuses through iteration. The application is quite straightforward for the people familiar with the SCRUM and Agile methodology.

Web site: https://github.com/SphereConsultingInc/easy_agile

* Redmine Kanban

The Redmine Kanban plugin is used to manage issues according to the Kanban system of project management.

Web site: https://github.com/edavis10/redmine_kanban

* Redmine Backlogs

Redmine Backlogs is still a work in progress but can already do a number of useful things for your agile team:
* Sort stories in your product and iteration backlogs
* Track story points for each of your stories
* Display burndown charts to show progress
* Track tasks via your iteration’s taskboard
* Produce printable task board cards
* Track impediments within each iteration

Web site: http://www.redminebacklogs.net/

* Redmine-Scrumbler

Redmine-Scrumbler is a Redmine plugin that allows to use the Scrum/Agile process in projects. Scrumbler have interactive dashboard with the ability to configure for each sprint. Plugin adds Scrum Points field in every issue in project. Scrumbler as possible using the standard redmine structure of projects.

Web site: https://github.com/256MbTeam/Redmine-Scrumbler

Redmine Scrumbler plugin dashboard

Redmine Scrumbler plugin dashboard

Plugins valid for older Redmine version

* Scrum PM

Scrum PM is a plugin for Redmine for Scrum project management. Redmine Version class becomes a sprint and issue becomes task. Most actions support drag and drop and in the dashboard you can change status of your task simply by dragging it to another column.

* Support for UML diagram generators railroad (Rails) and umlgraph (JAVA).
* One click documentation generation (rdoc and javadoc)
* Continuous integration with CruiseControl
* Burndown charts
* Velocity planing

Web site: http://www.software-project.eu/EN/scrumpm
Web site: https://github.com/software-project/scrum-pm

* Version Burndown Charts

Version Burndown Charts Plugin create burndown chart graph for Scrum from ticket’s estimated hours and %Done in target version.

Web site: https://github.com/daipresents/redmine_version_burndown_charts

* Redmine Todos-Scrum Plugin

Development stopped in 2010. A nested, easy to use project based todos plugin for Redmine. Allows easy creation and management of infinitely nestable todo lists on a per project basis, that can be organized into sprints(or releases). Also provides global ‘My Todos’ for all projects. Todos can be allocated to uses, and tied to Redmine Issues.

Web site: https://github.com/dalyons/redmine-todos-scrum-plugin

* Scrumdashboard

Development stopped in 2009 “Scrumdashboard” is a plugin for Redmine. It enables Redmine to better support the Scrum process by giving the users access to a digital “dashboard”. This shows the status for the current sprint through a digital representation of a whiteboard with post-it notes detailing User Stories/Features/etc (from the product backlog) which is often used with projects using Scrum.

Scrumdashboard supports the following:
* Drag & Drop to change the status of an issue, following the workflow
* Change the types of statuses/trackers displayed on the dashboard
* Column sorting for statuses
* Choose which version to display on the dashboard
* Tooltips for each issue
* Display all the issues or only the issues assigned to the current user
* Configure colors for issues displayed

Web site: https://github.com/thus/redmine-scrumdashboard-plugin