It is 28 years ago when the “New New Product Development Game” article was published by Takeuchi & Nonaka – the foundation for the Scrum thinking by Jeff & Ken. The principle of the article still stands strong: hand-offs between people make for a slower process than teamwork. The Agile Manifesto captured this in the first value “People & Interactions over Process & Tools”. All people in the agile world recite the manifesto and the “People over …” value, but do we all live by it.
Over the past years more and more focus was given to Scrum, often in a context of “building products better, faster, cheaper”. Most attention is given to the simple Scrum process, and discussions on the different how-to aspects, scaling the process, and the infamous ScrumButs are numerous. And good – you have to get good at a process when you want it to work in your favor.
Ten years into my agile experience I find that the process has limitations when it comes to faster-better-cheaper. But people do not – the intelligence of people will always overcome a hurdle, sometimes slowly, and always certainly. Let’s go back to the Takeuchi/Nonaka statement: bring all required skills into a team, and together they find problems and solutions early in the development process, preventing the development process from re-cycling when product issues are discovered late. Translating this to Scrum it means that the Scrum Team has to become the team. Not the development team – testers working close to coders etc. But also the Product Owner working daily with and for the developers, the Scrum Master working for the Developers and Product Owner to remove impediments, and the developers giving their best every day to help each other, to self-organize themselves out of obstacles and to always support the Product Owner in her endeavors to build the best possible product. Now that is a team, and team building will take time, can be frightening, and oh-so rewarding.
“Scrum Alliance, Scrum.org, and Scrum Inc. announce the release and joint endorsement of a new community website, ScrumGuides.org. The new website is the official source of “The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game.” Great news that brings clarity to people who wonder what the source of Scrum is, there is now a single source!
Occam’s razor states that among competing hypotheses, the one with the fewest assumptions should be selected. Other, more complicated solutions may ultimately prove correct, but—in the absence of certainty—the fewer assumptions that are made, the better.
In product development we have many assumptions, and little time to think them through, experiment and collect proof for the best solutions. When using Scrum the collection of data is moved to the real world: build the simplest thing that could possibly work (not simpler), and use it. Then collect data to support the decisions made and set the goals for the next step.
Lean Product Development uses set based development as an approach to select the best possible solution out of a set. The decision on which solution to use is delayed as long as possible (not longer) while working on multiple solutions at the same time until the collected data indicates which solution to choose.
The iterative principle of Scrum supports both philosophies, generating the opportunity to inspect and adapt fast, starting with the simplest possible solution.
Scrum Scales Quickly for Large Projects
Large scale scrum:
How we can manage change and still create stability and continuous delivery.
Scrum scales quickly. All it takes is three or more teams before many challenges arise, such as: communication, coordination, priorities and more. There are solutions for how to manage change, maintain stability, yet continuously deliver. Hubert Smits, CST, provides solutions to this question and many other challenges when Scrum Scales for large projects.