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).