Scrum – A Pocket Guide – 3rd edition

Gunther Verheyen

• Publisher: Van Haren Publishing
• Year: 2021
• ISBN:
  9789401807364
• Edition: 3
• Topic: Education
• Subtopic: Education General

This pocket guide to Scrum is the one book for everyone who wants to learn or re-learn about Scrum. The book describes the framework as it was designed and intended, with a strong focus on the purpose to the rules and adding an historical perspective to Scrum and the Agile movement. As the balance of society keeps shifting from industrial labor to digital work, complexity and unpredictability keep increasing. The need for agility through Scrum increases equally, in and beyond software and product development. This 3rd edition of Scrum - A Pocket Guide, while introducing some changes in terminology, more than ever offers the clarity and insights on Scrum that many organizations need, more than ever. It will help people and their organizations properly shape their Scrum, regardless of their domain or business.Scrum – A Pocket Guide is an extraordinarily competent book. It flows with insight, understanding, and perception. This should be the de facto standard handout for all looking for a complete, yet clear overview of Scrum without being bothered by irrelevancies. (Ken Schwaber, Scrum co-creator)The author, Gunther Verheyen, is a seasoned Scrum practitioner (2003). He has been employing Scrum since 2003. He was partner to Ken Schwaber and Director of the Professional Scrum series at Scrum.org. He is the founder of Ullizee-Inc and engages with people and organizations as an independent Scrum Caretaker on a journey of humanizing the workplace with Scrum.

1 The Agile Paradigm

■ 1.1 TO SHIFT OR NOT TO SHIFT

The software industry was for a long time dominated by a paradigm of industrial views and beliefs, based on and consisting of old manufacturing routines and theories. An essential element in this landscape of knowledge, views and practices was the Taylorist¹ conviction that ‘workers’ can’t be trusted to intelligently, autonomously and creatively perform their work. They are expected to only carry out pre-defined, executable tasks. Their work must be prepared, designed and planned by more senior staff. And then still, hierarchical supervisors must vigilantly oversee the execution of these carefully prepared tasks. Quality is assured by admitting the good and rejecting the bad batches of outputs. Monetary rewards are used to stimulate desired behavior. Unwanted behavior is punished. The old ‘carrots and sticks’ strategies.

Figure 1.1 The industrial paradigm

The serious flaws of the old paradigm in software development are known and well documented. In particular, the Chaos reports of the Standish Group [Standish, 2011; Standish, 2013] have over and over revealed the low success rates of a traditional approach in software development. Many shortcomings and errors resulting from the application of the industrial paradigm in software development are well beyond reasonable levels of tolerance. The unfortunate response seems to have been to lower expectations. The definition of ‘success’ in the industrial paradigm is made up of the combination of on time, within budget and including all scope. It became accepted that only 10-20% of software projects were successful. Although these criteria for success can be disputed, it is the paradigm’s promise. It became accepted that quality is low, and that over 50% of features of traditionally developed software applications are never used [Standish, 2002; Standish, 2013].

Although it is not widely and consciously admitted, the industrial paradigm did put the software industry in a serious crisis. Many tried to overcome this crisis by fortifying the industrial approach. The exhaustiveness of the upfront work was increased. More plans were created, more phases scheduled, more designs made, more work was done upfront, hoping that the actual work would be executed more effectively. As the success rates did not increase, in the industrial paradigm it is assumed that the instructions are not clear and detailed enough. But the core idea remained that the ‘workers’ needed to be directed. Supervision was increased and intensified. Even more detailed instructions were given.

Yet, little improved. Many flaws, defects and low quality remained and had to be tolerated.

It took some time, but inevitably new ideas and insights started forming upon observing the significant anomalies of the industrial paradigm.

The seeds of a new world view were already sown in the 1990s. But it was in 2001 that these resulted in the formal naming of ‘Agile’, a turning-point in the history of software development. A new paradigm was born, in the realm of the software industry. It is a paradigm that thrives upon heuristics and creativity, upon the (restored) respect for the creative nature of the work and the intelligence of the ‘workers’. In the meantime, it is also expanding to many other domains of society.

Figure 1.2 The Agile paradigm

The software industry has good reasons to keep moving to the new paradigm. The existing flaws are significant and widely known while the presence of software in society grows exponentially, making it a critical aspect of our modern world. However, by definition, a shift to a new paradigm takes time. And the old paradigm seems to have deep roots and a considerable half-life time. An industrial approach to software development continues to be taught and promoted as the most appropriate one.

Many say that Agile is too radical and they, therefore, propagate a gradual introduction of Agile practices within the existing, traditional frames. However, there is reason to be very skeptical about such gradual evolution, a slow progression from the old to the new paradigm, from waterfall to Agile.

The chances are high that a gradual evolution will never go beyond the surface, will not do more than just scratch that surface. New names will be installed, new terms and new practices will be imposed, but the fundamental thinking and behavior remain the same. Essential flaws remain untouched; especially the disrespect for people that leads to the continued treatment of creative, intelligent people as mindless ‘workers’, as ‘resources’.

The preservation of the traditional foundations keeps existing data, metrics and standards in place, and the new paradigm will be measured against those old standards. Different paradigms by their nature however consist of fundamentally different concepts and ideas, generally mutually exclusive. No meaningful comparison between the industrial and the Agile paradigm is possible. It requires honesty to accept the serious flaws of the old ways. It requires leadership, vision, entrepreneurship and persistence to embrace the new ways, thereby abandoning the old thinking.

A gradual shift is factually a status-quo situation that keeps the industrial paradigm intact.

There is overwhelming evidence that the old paradigm doesn’t work. Much of the evidence on the better results of Agile used to be anecdotal, personal or relatively minor. The Chaos report of 2011 by the Standish Group [Standish, 2011] marked a turning point, holding clear research results for the first time that were confirmed in all later Chaos reports. Extensive research was done in comparing traditional projects with projects that used Agile methods. The report shows that an Agile approach results in a much higher yield, even against the old expectations of delivery on time, on budget and with all the promised scope. The report shows that Agile projects were three times as successful, and there were three times fewer failed Agile projects compared to traditional projects. For large projects the changes in success rates were less outspoken, which is likely more due to starting with the wrong expectations in the large, i.e. the combination of time+budget+scope. Against the right expectations, with a focus on active customer collaboration and frequent delivery of value, the new paradigm would be performing even better, with frequent delivery of vertical slices of value to overcome the volume problem.

Yet, Agile is a choice, not a must. It is one way to improve the software industry. Research shows it is more successful.

Scrum helps.

Scrum is a tangible way to adopt and ingrain the Agile paradigm. The distinct rules of Scrum help in getting a grip on the new paradigm. The small set of prescriptions allows immediate action and results in a more fruitful, long-term absorption of the new paradigm. Using Scrum, people do develop new ways of working; through discovery, experimentation-based learning and collaboration. They enter a new state of being, a state of agility. This process helps their organizations transform towards such a state of agility too; a state of constant change, flux, evolution and adaptation. It allows freeing up time, people and energy for being innovative (again).

Nevertheless, despite its minimalism, experience shows that adopting Scrum often represents a giant leap. This may be because of the uncertainty induced by letting go of old certainties, even if those old certainties have proven not to be very reliable or…certain. It may be the time that it takes to make a substantial shift. It may be the determination and hard work that is required. Over and over again it is shown that Scrum is simple, not easy.

■ 1.2 THE ORIGINS OF AGILE

Despite the domination of the plan-driven, industrial views, an evolutionary approach to software development is not new. Craig Larman has extensively described the historical predecessors of Agile in his book ‘Agile & Iterative Development, A Manager’s Guide’ [Larman, 2004].

But the official label ‘Agile’ dates from February 2001, when 17 software development leaders gathered at the Snowbird ski resort in Utah. They discussed their views on software development in times when failing waterfall approaches were replaced by heavy-weight RUP implementations (‘Rational Unified Process’), which did not lead to better results than the traditional processes. These development leaders were following different paths and methods, each being a distinct expression of what would become the new, Agile paradigm; Scrum, eXtreme Programming, Adaptive Software Development, Crystal, Feature Driven Development, etc.

The gathering resulted in assigning the label ‘Agile’ to the common principles, beliefs and thinking of these leaders and their methods. They were published as the ‘Manifesto for Agile Software Development’ [Beck, et.al., 2001].

Often the desire “to do Agile” or “to go Agile” can be overheard. And all too often it is the desire for a magical solution, another silver bullet process that solves all problems. It makes me often state that “Agile does not exist”. Agile is not a fixed process, method or practice. Agile is the collection of principles that the methods for Agile software development have in common. Agile refers to the mindset, the convictions and the preferences expressed in the Manifesto for Agile Software Development.

Figure 1.3 The Agile Manifesto

The Manifesto helps to grasp the ideas underpinning Agile. If you use it as a source to gain a deeper understanding of Agile, then I strongly advise looking at the twelve principles behind the four value statements, see http://agilemanifesto.org/principles.html.

■ 1.3 DEFINITION OF AGILE

In the absence of a concise, specific definition I prefer describing ‘Agile’ in terms of three key characteristics. These are the traits that are common to the portfolio of Agile methods and are typical to an Agile way of working:

■ People driven;

■ Iterative-incremental process;

■ Value as the measure of success.

1.3.1 People Driven

Agile is not driven by a predictive plan on how to implement requirements that were exhaustively analyzed, designed and...