Kanban or Scrum? – First Generation Agile Methods

I found again some very interesting wrong interpretations about how Scrum works.

Kenji Hiranabe and I discussed this point over a year ago before his second Kanban articlefor InfoQ. I argued and I believe Kenji concurred that Agile methods like Scrum are really small batch transfer push processes. There is no explicit pull system within a Sprint and it’s a stretch to suggest that the batch transfer at the beginning of a Sprint – the selection of the backlog – is a truly “pull” process. It is never described this way. It is described as a negotiation where the team estimate a set of stories that the product owner wants done. They compare the estimate with the previously achieved velocity and decide what can be fitted into the available time in the Sprint. If it were truly a pull system then there wouldn’t be any negotiation. The product owner would have a prioritized backlog and the team would simply pull the top (however many) stories from it and start work. (more …)

I do not want to argue about, if Scrum is a pull system or not – because everybody who does Scrum correctly knows it is a pure pull system and if you understand to what every Scrum teams evolves it practices than you will see that there is absolutely no difference between Kanban ideas and what Scrum does. The real point is:

They are both on different levels. Henrik Kniberg, has written an excellent article about Scrum and Kanban and does a really interesting mistake in this article:

Scrum and Kanban are both process tools

Tool means “anything used as a means of accomplishing a task or purpose” (dictionary.com). Process means how you work. Scrum and Kanban are process tools in that they help you work more effectively by telling you what to do. Java is a tool, it gives you a simpler way to programming a computer. A toothbrush is a also a tool, it helps you reach your teeth so you could clean them. (Henrik Kniberg, Kanban vs Scrum -A practical guide)

Although Ken always refer Scrum as a framework:

Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory*. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Within each iteration, Scrum employs self-organizing, crossfunctional Teams to optimize flexibility and productivity (Scrum Guide, Scrum Alliance)

Scrum is much more than a tool. And Scrum is definitely not “only” a tool. Scrum is a mindset, in the same sense as the Toyota Production System was always a mindset a philosophy and not only a tool:

What is the secret of Toyota’s success? The incredible consistency of Toyota’s performance is direct result of operational excellence. Toyota has turned operational excellence into a strategic weapon. This operational excellence is based in part in tools and quality improvement methods made famous by Toyota in the manufacturing world, such as just-in-time, kaizen, one-piece flow, jidoka, and jeijunka. These techniques helped spawn the “lean manufacturing” revolution. But tools and techniques are no secret weapon for transforming a business. Toyota’s continued success at  implementing these tools stems from a deeper business philosophy based on its understanding of people and human motivation. Its success is ultimately based on its ability to cultivate leadership, teams, and culture, to devise strategy, to build supplier relationships, and to maintain a learning organization. (The Toyota Way, Liker, p. 6)

You can translate / rewrite this whole paragraph for Scrum:

What is the secret of Scrum enforcing companies. …. This operational excellence is based in part in tools and quality improvements made famous by the agile software development movement: test driven development, continuous integration, pair programming, one-story-at the time, the task board …. the continuous success steems from a deeper business philosophy that is embedded in Scrum: we value transparency, honesty and  courage and we believe in people are adults, they can make decisions, they want to achieve things and  a lot of more things.

People who want to see Scrum as a tool, do not see that all these tool thinking leads again and again back to the idea that Scrum is a silver bullet or a methodology or a process tool. It is NOT!

The second thought I want to make clear here:

Scrum like all early (first generation) Agile methods really do not change the project management paradigm very much. They still use projects as the frame of reference and still have the triple-constraint (iron triangle) of scope-schedule-resources as an underpinning. (more …)

That is wonderful: The whole idea is incredible: Scrum is a first generation agile method! That is b….t

Scrum is now the de facto agile software development standard as it has evolved from the idea from managing a project to managing whole enterprises using Scrum. Scrum always talked about value adding, Scrum brought the whole flow idea into the agile community. Lean is a subset of all this – as we learn in Likers, Toyota Way that Lean is only a subset of the Toyota Way.

So comparing Scrum with Lean is nonsense as Scrum is lean by definition.

To enhance practices of people that try to develop software within Scrum by using some more clever ideas how to use a taskboard (btw, it was invented by the XP people and then transformed in the de facto work standard by Tobias Mayer and me) for Scrum teams are fully embraced by all Scrum people.

Because — Scrum teams use what works to make them more successful. They want to become truly knowledge based teams using all ideas about how to establish a the learning organization (Senge).

2 responses to “Kanban or Scrum? – First Generation Agile Methods

  1. Scrum is not Lean. Scrum didn’t come before Lean. There is no chicken and egg here. Lean existed way before Scrum. When I took my CSM class from Jeff Sutherland, he discussed Lean, ToC, and Systems Thinking concepts as inputs to the design of Scrum. When Scrum was evolving from a bunch of smart people applying these practices, it was viewed as the growth and extension of the practices. Wrapping names like Scrum and XP around these new sets of practices creates a set of common language, principles, and methods that could be taught and expanded upon.

    Scrum is about software development and for the most part within small teams. It was specifically established as something that could be rapidly implemented and provide the basis for ongoing learning (inspect and adapt/remove impediments).

    What is going on now is that there is a growing community that have led and participated in Scrum development teams who have also studied Lean, Theory of Constraints, Real Options, and other concepts. They have identified some practices that appear to work well across large teams, across multiple products, and beyond the boundaries of software development.

    Kanban (capital K), is an encapsulation of a number of these practices. It has grown out of the practical application of these developers. While wrapping some shared language around common practices might seem to devalue Scrum or take some of the mysticism out of the Scrum Master role, putting some names and descriptions around these best practices is useful to the community as a whole.

    Overall, this is not a bad thing and it is not an indictment of Scrum. I don’t believe the discussion of Kanban (capital K) reduces the value of Scrum on bit. I believe that it is part of an ongoing evolution, of which Scrum was a major step. After all, I don’t think we have this software development thing perfectly figured out. We still trying to improve they ways we develop software and help others do it.

  2. Hi Bas, glad you enjoyed the article!

    > Henrik Kniberg, has written an excellent
    > article about Scrum and Kanban and
    > does a really interesting mistake in this article
    What was the mistake?

    > Scrum is much more than a tool.
    > And Scrum is definitely not “only” a tool.
    Tool means “anything used as a means of accomplishing a task or purpose”. So how is Scrum not a tool?

    If I say “My wife is a good piano player”, does that mean she is “only” a piano player?

    > People who want to see Scrum as a tool,
    > do not see that all these tool thinking
    > leads again and again back to the idea
    > that Scrum is a silver bullet
    I strongly disagree. Thinking of it as a tool actually counteracts silver-bullet thinking – because everyone knows that a tool on it’s own will never solve anything.

    Thinking of it as a tool also reminds people that there are other tools out there as well. Scrum isn’t the only tool you should carry in your kit.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s