Scrum Guide 2020 vs 2017 Part 1: The Foundations (from a hardware perspective)
Scrum Guide 2020 vs 2017 Part 1: The Foundations (from a hardware perspective)
This will be a multiple part article. In this first post we will focus on how theory is explained in the updated guide. Coming articles will cover Empiricism, The Scrum Team, Events and Artifacts.
At MEQIFY we have long experience of applying Scrum and other agile frameworks outside of the pure software industry. We have developed specific expertise and good practices for usage of Scrum in Hardware. We are now co-authoring this series to give you our collective insights on the effect on manufacturing companies and Hardware design companies.
We are happy to see that Lean is now a cornerstone of good Scrum. This is not really news; Lean has always been core but not explicitly mentioned. The hardware industry has a lot to learn from software, but software has a lot to learn from modern manufacturing as well!
The importance of a Scrum Master to succeed is now stated very early on. We find that we often must argue the importance of this role (we will come back to the Scrum Master description in coming articles). We see so many missed opportunities to build high performing teams and so many lessons not learned when the Scrum Master is not seen as important or senior Agile coaching support is lacking.
Scrum has always been a framework, not a process, but often mistaken as one. Now when the practices are purposely omitted you need to start thinking more about Why. Good practices are heavily dependent on your own context and needs. We are looking forward to seeing what good practices will emerge from experimentation outside of the beaten software path.
Impact on Hardware companies doing Scrum
When people hear us talking about Scrum for Hardware, we often get the reaction “That sounds hard!”. Yes, it mean increased complexity, and that’s why Scrum is even MORE powerful in hardware than in software. We are happy that more and more companies realize this, and it is great to see that endorsement stated. All you out there that have succeeded with Scrum in Hardware. Contact us and let us together collect good practices to complement the new and less prescriptive guide.
Most manufacturing companies today are already using, or are inspired by Lean Product Development, and have developed a lot of great internal practices. The new guide makes it clear that you should not change what is already working in your specific environment! Since the new guide explains more about “Why Scrum works” (but we think it can be even further improved), it is easier to understand what to keep and what to remove. We have a lot of experience in how to do this in practice and a pattern we see is that useful stuff is usually around engineering practices and short checklist (the “How”) and the non working parts are around project-handling (governance, organization, flow and budget). Product-centric stuff works, but project related stuff slows you down!
Impact on Hardware companies about to implement Scrum
We have always believed, and now we have a lot of empirical evidence as well, that a bottom-up implementation is the way to go. The new guide uses a much softer language on how to start with Scrum than before. Try it, evaluate the value and find bottlenecks, improve, repeat. To be able to do that you need experienced Scrum Masters with domain knowledge to help you identify and remove those roadblocks. Over the years we have collected an ever-growing toolbox of good practices to try out when you get stuck (external dependencies, risk management, regulatory compliance, long lead times and test cycles, diverse competences and more). Even if you start small, make sure you have a champion in management that can support you when you interface with the rest of the organization.
Lean is just as much about culture change as process improvements. Cultural change takes time, and just because you have a few teams running, it does not mean that you have transformed. A good health check is to see what happens during extreme pressure or force majeure. If your reaction to change is trust and empowerment, please get in touch so we can learn. If you go back to command-and-control you need more support. Take a step back and reflect on how you as leaders have reacted and what you can learn from that.
There has been a focus from the authors of guide to get rid of software-specific language. We have not had big issues with explaining that language to the teams, but higher up in the organization its harder and harder. “Empirical process control theory” has been replaced by “Lean thinking” and the latter is way easier to use as common language in those discussions.
Changes between 2020 and 2017 version
Purpose of the scrum guide
We developed Scrum in the early 1990s. We wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum. We have evolved the Guide since then through small, functional updates. Together, we stand behind it.
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.
Scrum is a framework for developing, delivering, and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.
Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:
- Research and identify viable markets, technologies, and product capabilities;
- Develop products and enhancements;
- Release products and enhancements, as frequently as many times per day;
- Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
- Sustain and renew products.
Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.
As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily.
Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization.
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.
When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Simple to understand
Difficult to master
Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.
The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.
Specific tactics for using the Scrum framework vary and are described elsewhere.
Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.
Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.