35,99 €
Mehr erfahren.
- Herausgeber: WS
- Kategorie: Fachliteratur
- Sprache: Englisch
Ultimate Scrum - a comprehensive guide created from 20 years of experience helping 250,000 people learn Scrum and Agile. For an investment of less than $50 and 1 day, you get the equivalent of $20,000 of professional training and 200 hours of classroom learning.
Whether you’re a beginner or a pro, this book will help you. Learn at your own pace with concise overviews of essential topics. Start or continue your Scrum journey.
The goal of Ultimate Scrum is simple: to make learning Scrum & Agile fast, easy and low-cost. You’ll find only essential content here with no filler.
This book provides short, digestible coverage of a wide range of topics, including popular frameworks, methods, approaches, practices and tools. It is intended to be the "almost complete works of Scrum”. It is only “almost complete” because new insights are constantly emerging.
What Readers Say
“Well written, simply explained and with easy-to-follow examples that make the subject matter easy to understand. I also enjoyed the shared experiences.”
- Ricardo
“This totally gets to the heart of what being an effective Scrum Master is all about. There are also some excellent personal stories shared throughout which helps give further meaning and fully brings things to life. Without hesitation - all practicing and aspiring Scrum Masters should read this!”
- Paul
“As a product owner, reading Ultimate Scrum gave me a great refresher of the fundamentals of the role in a way that was clear, concise and easy to digest.”
- Philip
“I really like this book. It is not just a description of the Scrum theory in general, it comes with many tips from the daily work with Scrum and is easy to understand, even for people that are completely new to Scrum.”
- Claudia
“I have read a number of books on Agile and the Scrum Framework. What I particularly liked about the Ultimate Scrum Book was the depth and breadth. It can also be picked in bite-size chunks if you want to read about a certain section. This book would be great for someone interested in getting a vast overview of Scrum and Agile who may not have been exposed to it before. I can also see it being valuable to an experienced practitioner looking to get some enhanced knowledge on a topic they are less familiar with. Highly recommended.”
- Nick
“Simple and straightforward, clearing out the confusion you may find out there.”
- Fernando
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 654
Veröffentlichungsjahr: 2024
Ähnliche
Contents
Welcome
Copyright
Introduction
About Ultimate Scrum
About Scrum
Ultimate Applying Scrum
Introduction
What Is Agile?
The Agile Manifesto
What Is Scrum?
The Benefits of Scrum & Agile
Scrum in 3 Minutes
What You Need To Know About Scrum
History Of Scrum
Complexity & Empiricism
Scrum Team
Why Do We Need a Scrum Team?
Product Owner
Why Do We Need a Product Owner?
Scrum Master
Why Do We Need a Scrum Master?
Developers
Stakeholders
Artifacts & Commitments
Product Backlog
Product Goal
Sprint Backlog
Sprint Goal
Product Goal & Sprint Goals – Why They Are Important?
Product Goal & Sprint Goals – A Simple Example
Increment
Definition of Done
Definition of Done – A Simple Example
Events
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Product Backlog Refinement
Scrum Values
Sprint Cancellation
Uses of Scrum – Software
Uses of Scrum – Beyond Software
Summary
Ultimate Scrum Product Owner
Introduction
Why Agile & Scrum?
Agile Product Management
What Is a Product?
Project vs Product
Product Management Vacuum
Vision & Strategy
Value
Information Neutrality
Negative Value
Release Costs
Validation
Evidence-Based Management
Product Backlog Refinement
User Stories
Story Mapping
Impact Mapping
Planning
Releases
Estimation & Velocity
The Cone of Uncertainty
Budgeting
Fixing Budget, Scope & Time
Governance
Quality
Definition of Done
The Best Product Owners I Ever Worked With
Tips To Improve as a Product Owner
Summary
Ultimate Scrum Product Owner Advanced
Introduction
What Is a Product Owner?
Misunderstood Stances of the Product Owner
Preferred Stances of the Product Owner
Product Strategy
Value
Product Wall
Product Roadmaps
Product Owner at Scale
Decision Making
Pricing
Pricing Strategies
Governance
Rolling Wave Forecasting
Agile Contracts
Understanding Stakeholders
Saying No To Stakeholders
Summary
Ultimate Scrum Master
Introduction
What Is a Scrum Master?
Leader & Servant
Leadership Styles
Complexity & Management Style
Self-Managing Scrum Team
Simple But Not Easy
Forming Scrum Teams
Sustainable Pace
Multitasking
Motivation
Team Working Agreements
Services to the Scrum Team
The Best Scrum Masters I Ever Worked With
Don’t Be a Comfortable Scrum Master!
Being A Scrum Master Is Hard
Summary
Ultimate Scrum Master Advanced
Introduction
Principles & Values
Common Myths About Scrum
Complementary Practices
Successful Scrum Teams
Three Questions at the Daily Scrum
Conflict
The Importance of Done Increments
The Importance of Goals
Management in Scrum
Measurement
Velocity
Burn Down And Burn Up Charts
Misunderstood Stances of the Scrum Master
Preferred Stances of the Scrum Master
Change Agent
Facilitation
Coaching
Teaching
Mentoring
Summary
Ultimate Evidence-Based Management
Introduction
History of Evidence-Based Management
Vision, Mission & Goals
Goals, Measures & Behaviours
Inputs, Activities, Outputs, Outcomes & Impacts
Leading & Lagging Indicators
DailyMail.co.uk Value Measures
Goal Levels
Goals in Action at TheScrumMaster.co.uk
Key Value Areas (KVAs)
Key Value Measures (KVMs)
Measurement in Action at TheScrumMaster.co.uk
Empiricism
SMART Goals
SMART Goals in Action at TheScrumMaster.co.uk
Objectives & Key Results (OKRs)
Investing for Agility
Summary
Ultimate Scrum With User Experience
Introduction
What Is Lean UX?
History of Scrum & UX
Scrum & UX Fundamentals
Lean UX Canvas
Business Problems
Business Outcomes
Outcomes Over Outputs
Pirate Metrics
Users & Customers
Proto-Personas
Customer Interviews
User Outcomes & Benefits
Solutions
Hypotheses
The Hypothesis Prioritization Canvas
What’s The Most Important Thing We Need To Learn First?
What’s The Least Amount Of Work We Need To Do To Learn The Next Most Important Thing
The Truth Curve
Experimentation Practices
Minimal Viable Product
Managing UX Work in Product Backlogs
Core Concepts of Scrum & Lean UX
Summary
Ultimate Scrum Product Backlog Management Skills
Introduction
Product Backlog
Product Goal
Stakeholders
Product Backlog Management
Product Backlog Refinement
Product Backlog Ordering
Product Backlog Item Decomposition
Product Backlog Item Attributes
Product Backlog Item Formats
Product Backlog Item Slicing
Product Backlog Item - INVEST Criteria
Product Roadmaps
Now-Next-Later Product Roadmap
Goal-Oriented Product Roadmap
Summary
Ultimate Agile Leadership
Introduction
What Is Agile?
Business People & Developers Must Work Together Daily
Effective Communication
Become More Effective
Sustainable Pace
Motivated People
Early Value Delivery
Simplicity
Complexity & Management Style
Self-Management
Focus Areas Of An Agile Leader
Leadership & Delegation
Planning & Estimation in a Nutshell
Evidence-Based Management
Growing Agility
WAGILE Is Not Agile
Summary
Ultimate Scaled Scrum With Nexus
Introduction
The Nexus Framework
The Foundations for Scaling
The Cost of Scaling
The Secret to Scaling Scrum
Nexus Artifacts
The Nexus Integration Team
Cross-Team Refinement
Nexus Sprint Planning
Nexus Daily Scrum
Nexus Sprint Review
Nexus Sprint Retrospective
Nexus+
Summary
Ultimate Scrum For Software Development
Introduction
Complementary Practices
Uncertainty
Spikes
Story Points
Velocity
Poker Planning
Flow Metrics
DevOps
Quality Measures
Productivity Measures
Testing
Pairing & Mobbing
Emergent Architecture
Quality Code
Test First
Build Automation
Source Code Control
Ultimate Scrum With Kanban
Introduction
History of Kanban
Benefits of Kanban
Flow
Flow Metrics
Kanban Charts
Little's Law
Workflow Visualization – The Kanban Board
Limiting Work in Progress (WIP)
Active Management of Work Items in Progress
Flow-Based Scrum Events
Monte Carlo Simulation
Summary
Ultimate Scrum Facilitation Skills
Introduction
Facilitation Myths
Facilitation Principles
Facilitation Skills
Group Dynamics
Diamond of Participatory Decision-Making
Building Consensus
Decision Making Rules
Facilitating Scrum Events
Liberating Structures
1-2-4-All
Troika Consulting
15% Solutions
White Elephant Facilitation
Summary
Ultimate Scrum Practices
Introduction
Scrum Is Incomplete by Design
Sprint Planning Strategies
Sprint Backlog Strategies
Daily Scrum Strategies
Sprint Review Strategies
Sprint Retrospective Strategies
Definition of Done Strategies
Product Backlog Refinement Strategies
Stable Teams
Swarming
Automation
Sprint Scheduling
The Evening Daily Scrum
The Scrum Team Charter Canvas
Summary
Ultimate Product Discovery & Validation
Introduction
Defining Work As Problems To Solve
Business Problem Statements
The Truth Curve
Experimentation Practices
Designing & Running Experiments
Product-Led Companies
DIBB Framework
The Double Diamond Method
Learning From Users
Proto-Personas
Impact Mapping
Problem Fit, Solution Fit & Market Fit
Assessing Opportunities
The Hypothesis Prioritization Canvas
Product Discovery & Validation With Scrum
Summary
Appendix
About The Author
Learn More
What Did You Think?
Acknowledgements
Notes
Guide
Contents
Start of Content
ULTIMATE SCRUM
Simon Kneafsey
The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise.
Copyright © 2024 No Limits Media Solutions Ltd
ISBN: 9781739163839
INTRODUCTION
About Ultimate Scrum
Welcome to the Ultimate Scrum book. This is my effort to capture everything I have learned about Scrum and Agile over the last 20 years. My organisation, TheScrumMaster.co.uk, is on a mission to simplify Scrum & Agile for 1 million people. We have helped 250,000+ people so far and are here to support you, too.
Whether you're new to Scrum or seasoned in Agile, this book is designed to provide you with quick, digestible overviews of essential topics. Think of it as the "almost complete works of Scrum"—and I emphasise “almost” because it can never be complete, with new practices and insights emerging constantly.
For the price of the book, you will get the equivalent of $20,000 worth of professional training and over 200 hours of classroom knowledge distilled into just a few hours of reading. A bargain! The goal is simple: to make learning Scrum & Agile fast, efficient and low-cost without bogging you down with needless filler content. You’ll find only what’s essential here.
Learning in a live class alongside others is wonderful. However, such live classes come with some downsides. To attend, you must clear days from your calendar to focus exclusively on the content. You must attend the entire class even if you are only interested in parts of the content. If attending in person, you must travel, which takes time and costs money.
We need new learning methods that fit our existing commitments, allow us to learn in short bursts, and are less expensive. We also need to be able to learn the specific things we want.
Feel free to jump between sections, skip parts that don’t resonate with your current needs, and return to this book as a reference whenever you need it. This flexibility puts you in control of your learning journey. Dive in and start or continue your learning journey now.
About Scrum
Scrum is a lightweight framework that helps people create value when doing complex work. It helps people develop products where there is a high level of uncertainty and change. Scrum in a nutshell:
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 the plan & process for the next Sprint.
Repeat.
Scrum is simple to learn and use. It helps people to work iteratively and incrementally using an empirical approach. Empiricism encourages increased transparency, inspection, and adaptation. It exposes issues and real progress as early as possible and encourages people to make changes to increase their chances of success.
Ken Schwaber and Jeff Sutherland created Scrum in the 1990s. Scrum was initially used to build software, but is now used by tens of millions of people worldwide to help solve complex challenges, and this number is growing rapidly. You can read the Scrum Guide for the official definition of Scrum.
I have been working with Scrum for over 20 years and have helped hundreds of organisations and thousands of people to use it to improve their ability to deliver value. I have seen people build incredible products and help their organisations to improve.
ULTIMATE APPLYING SCRUM
Introduction
Discover how to use Scrum to improve your ability to deliver value. Scrum provides an effective way of working that highlights experimentation, incremental value delivery, and regular feedback loops.
In this section, you will discover a new, Agile way of working. Learn the fundamentals of Scrum and how to use it well.
Section Learning Objectives
Learn (or relearn) the fundamentals of Scrum and how to apply them.
Learn about agility and how Scrum differs from traditional plan-driven work models.
Develop an Agile approach by focusing on experimentation and outcomes.
Understand how to identify common pitfalls and how to avoid them.
Learn a set of good practices that can be used to enhance your use of Scrum.
Who Should Read This Section?
This section is a perfect introduction, reboot or refresher to Scrum. It is domain-agnostic and suitable for people from all industries. Ideal for:
People new to Scrum who want to understand how to use it.
People using Scrum already who need a refresher to help them get more out of it.
What Is Agile?
Agile is the ability to respond to change while controlling risk. It is a way of dealing with and succeeding in an uncertain and changing environment. It is about understanding what is happening in your environment and adapting as you proceed.
Agile has emerged as a huge global movement. It enables organisations to succeed in an increasingly volatile, uncertain, complex and ambiguous world. The rate of change has accelerated dramatically over the past 25 years, and all indicators point to this trend continuing. Today's “fast enough” will likely not be fast enough in future. To remain competitive, organisations need a process that can help them keep up with this accelerating rate of change.
Agile frameworks like Scrum help organisations deliver products earlier and at lower costs, giving them a competitive advantage in a fast-paced market. They can rapidly adapt to meet the market’s and customers’ needs.
The Agile Manifesto
The Agile Manifesto was created in 2001. It was intended as a response to the heavyweight, documentation-driven software development processes that were in everyday use at this time. Software was a new industry. The first computers emerged shortly after the Second World War. For the following decades, only a few computers were in use. This changed in the 1980s and 1990s with the birth of the personal computer and the internet. In a few years, millions of people had begun creating software to help businesses gain a competitive advantage and provide new services for customers.
The volume of software in everyday use proliferated. A new industry was born. However, this new industry lacked effective processes, and many problems marked the early years. In many organisations, people did not understand or accept the complex nature of software product development. Irrational demands were often placed on people to complete a fixed scope of work by an unrealistic deadline. This prevented those involved from making vital trade-off decisions early enough in the product development process to avoid delays and overruns. It was common for projects to fail to deliver the outcomes that were initially intended, to deliver late, be over budget and have significant quality issues.
The industry was not in a good place. Low-value, low-quality products and frustrated and disengaged people were commonplace. The pattern repeated, company after company, project after project, year after year.
This was the reality of the industry when I joined it in the 1990s. For many organisations who have not yet embraced better working methods, it still is the reality!
Traditional management practices are not easily replaced. Agility means embracing change and identifying and accepting certain risks. This is uncomfortable for people who may have spent decades using traditional management practices to limit change and lower risk.
So what is Agile and agility? Well, let’s look at that manifesto. The values of the Agile Manifesto are:
Individuals and interactions
over
processes and tools
Working software
over
comprehensive documentation
Customer collaboration
over
contract negotiation
Responding to change
over
following a plan
While there may be value in the items on the right, we value the things on the left more. This is where the focus should be placed. You can find the Agile Manifesto at agilemanifesto.org.
There are 12 supporting principles which provide further details. You can find the principles at agilemanifesto.org/principles
So, Agile is a set of values and principles. It can be compared to a philosophy, and as such, it is widely open to interpretation. The term has been misused since the creation of the manifesto.
The manifesto is a set of values and principles. People interpret the meaning of these values and principles through their own life experiences, interests and biases. As a result, it means very different things to different people. I typically get ten different answers when I ask ten people what Agile is.
Despite this, taking an Agile approach is now the default way to develop products for most organisations today. However, transitioning to a new approach can be hard, and the benefits of adopting Agile must outweigh the cost. Here are the most common benefits of an Agile approach:
Faster delivery
Higher productivity and quality
Higher engagement, purpose and motivation
Lower costs and less waste
Improved stakeholder satisfaction
Improved predictability
Faster feedback & learning cycles
Embraces the reality of constant change
Easier to adapt and pivot
Reduced risk
The best definition of Agile is that it is about responding to change whilst managing risk. Those seeking to become Agile want to embrace change and make it an advantage whilst balancing the risk that this brings in a way that is safe enough in their current environment. So, there is not a one-size-fits-all way to be Agile. It depends on your desire for change and your risk tolerance. A small startup will naturally be more Agile than a large, hundred-year-old Bank. Frameworks such as Scrum can help people find their path to agility.
Scrum has emerged as the default way for those organisations to become more Agile. Scrum contains specific rules that, when used correctly, i.e. with the Agile values and principles in mind, can enable greater agility. Scrum is not the only way to be Agile, and Scrum does not guarantee agility.
What Is Scrum?
Scrum is a lightweight framework that helps people, teams, and organisations generate value through adaptive solutions for complex problems. It is simple to understand yet difficult to master.
Scrum implements the scientific method of empiricism to help people collaborate to do complex work. This is work where there is a high degree of uncertainty and unpredictability, and therefore, the probability of change is high. An empirical approach helps us find answers to the issues that emerge in these complex environments.
Scrum is not a methodology. It does not have all the answers to all the problems you will encounter when developing a product. It requires those who use it to find most of their solutions to the issues. No methodology or framework could have all the answers to developing products in complex environments where things are constantly and inevitably changing. Requirements, technology, practices, market forces, economics and regulatory factors are only some things that cannot be controlled entirely despite our best efforts.
Instead, Scrum is a minimal set of rules that guides peoples’ relationships and interactions. It will help you develop a product and expose your most significant issues as early as possible. By discovering the significant problems early, you can work to solve them while you have time and resources. Scrum is best described as a problem-finding framework!
Scrum helps you present an accurate and transparent picture of your current ability to develop your product. These truths can sometimes be painful to acknowledge, but should not be ignored.
Software development is a prime example of complex work, and it is from here that Scrum emerged in 1995. In the years following, the use of Scrum proliferated. Scrum co-creators Ken Schwaber and Jeff Sutherland wrote the first Scrum Guide in 2010 to explain the rules of Scrum to prevent some common misunderstandings and misrepresentations of Scrum.
The Scrum Guide is great, but it is not easy for those new to it all to read and understand. You can find the Scrum Guide at scrumguides.org. So, what is Scrum?
Scrum comprises three accountabilities, three artifacts and five events. The framework also details additional rules and guidelines. The fundamental unit of Scrum is a small team of people, a Scrum Team. Inside the Scrum Team, there are three accountabilities. These are:
Product Owner
Scrum Master
Developers
Scrum Teams are self-managing and cross-functional. Self-managing teams internally decide who does what, when, and how. Cross-functional teams have all the competencies needed to accomplish the work without depending on others outside the team.
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. The Scrum artifacts are:
Product Backlog
Sprint Backlog
Increment
Each of the artifacts in Scrum contains a commitment to them, which brings transparency and focus:
The Product Backlog has the Product Goal
The Sprint Backlog has the Sprint Goal
The Increment has the Definition of Done
The Scrum events are used to provide opportunities for inspection and adaptation. The five Scrum events are:
The Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Scrum contains specific rules that, when used correctly, can enable greater agility. It is the most widely used approach to become more Agile. Scrum is not the only way to be Agile, and Scrum does not guarantee agility. Like any tool, what you do with it makes the difference.
Scrum was very attractive to me when I first came across it. It can help you learn fast, collaborate effectively, lower risk, and deliver more value to your customers promptly and frequently. Here are some of my top tips for using Scrum:
Follow the rules of Scrum. These will act as guard rails to help you safely learn and adopt a new approach to complex work.
Foster an environment where the values of Scrum & Agile are understood, respected and enacted.
Take an empirical approach to your work, build trust, and learn quickly.
Stay close to your customers and release value to them as early and often as possible.
Simple!
Scrum is (or should be) simple! Unfortunately, it has been complicated for many years, but not any more. We are here to simplify Scrum for you.
The Benefits of Scrum & Agile
There are lots of good reasons to use Scrum to become more Agile. While using Scrum, new features are developed incrementally in short Sprints. At the end of each Sprint, a potentially usable Increment of product is available. This enables the product to be released much earlier in the development cycle, enabling benefits to be realised earlier than possible if we waited for the entire product to be “complete” before a release.
Maintaining quality is a crucial principle of development with Scrum. Testing occurs every Sprint, enabling regular inspection of the working product as it develops. This allows the Scrum Team early visibility of any quality issues and will help them make necessary adjustments.
Scrum encourages active Product Owner and stakeholder involvement throughout product development. Transparency is required around progress, which helps ensure that expectations are effectively managed.
Small Increments of working products are regularly visible to the Product Owner and stakeholders. This helps the Scrum Team to identify risks early and makes it easier to respond to them. The transparency in Scrum ensures that any necessary decisions can be taken at a suitable/earlier time while it can still make a difference to the outcome. The Scrum Team owns risks, and they are regularly reviewed. The risk of a failed initiative is reduced.
In traditional product development, we create extensive specifications upfront and then tell business owners how expensive it is to change anything, particularly as the project proceeds. We resist changes and use a change control process to keep change to a minimum. This approach often fails as it assumes we can know what we want with 100% clarity at the start of development (which we usually do not) and that no changes will be required that could make the product more valuable (which is unlikely with the speed of change in many organisations and markets today).
In Agile development, change is accepted and expected. The time scale is often fixed, and detailed requirements emerge and evolve as the product is developed. For this to work, it is imperative to have an actively involved Product Owner who understands this concept and makes the necessary trade-off decisions, trading existing scope for new scope where it adds greater value.
The approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable rather than the cost. As we develop complete slices of functionality, we can measure the actual development cost as it proceeds, giving us a more accurate view of the cost of future development activities.
The active involvement of a Product Owner, the high transparency of the product and progress and the flexibility to change when change is needed create more business engagement and increase customer satisfaction. This significant benefit can build more positive and enduring working relationships.
The ability for requirements to emerge, evolve, and embrace change helps ensure the Scrum Team builds the right product that delivers the anticipated value to the customer or user.
In more traditional projects, it is all too common to deliver a “successful” project and find that the product is not what was expected, needed or hoped for. In Agile development, the emphasis is placed on building the right product that will deliver the desired value and benefits.
Research suggests about 80% of all market leaders were first to market1. As well as the higher revenue from incremental delivery, Agile development supports the practice of early and regular releases.
The active involvement, cooperation and collaboration in successful Scrum Teams makes for a more enjoyable place to work. When people enjoy what they do, the quality of their work will be higher, and the possibility of innovation will be greater. Happy and motivated people are more efficient, effective, and likely to stick around.
Scrum in 3 Minutes
Here is a short overview of Scrum and how all the pieces fit together.
Work is completed in short cycles of less than one month, called Sprints.
The Product Goal represents the long-term objective for the Scrum Team and details why it is valuable. The work to be Done to reach the Product Goal is held in an ordered Product Backlog, which the Product Owner is accountable for. Items at the top of a Product Backlog are refined to a ready state by the Scrum Team so they are small enough, and enough is known about them, to allow them to be Done in a Sprint.
The Scrum Team conducts the Sprint Planning event at the beginning of each Sprint. They set a Sprint Goal that is the single objective for the Sprint and explains why the team is completing the work. The work to be Done and a plan of how to do it are captured in the Sprint Backlog. The Developers are accountable for this artifact.
During the Sprint, the Developers manage and work to produce a Done Increment that meets the Sprint Goal by the end of the Sprint. By the end of the Sprint, the Increment must be usable. A Definition of Done helps us understand the quality required for the Increment.
Producing a usable Increment that meets the Definition of Done and achieves the Sprint Goal each Sprint exposes issues and helps the team understand the risks and challenges they face. Finding such issues from the first Sprint ensures the Scrum Team has the maximum possible time to resolve them.
A self-managing and cross-functional Scrum Team carries out the work during the Sprint. This means they decide what, how, and when to do the work and have the skills and knowledge needed to complete it. Developers meet daily at the Daily Scrum to revisit and adapt the Sprint Backlog for the next 24 hours.
At the end of the Sprint, the Increment is inspected by the Scrum Team and stakeholders at a Sprint Review. More is now known about the product and the team’s domain. Incorporating these learnings and new ideas into the Product Backlog will help to deliver a more valuable product.
In the Sprint Retrospective, the Scrum Team seeks to overcome issues and improve its product creation ability.
The Scrum Master is accountable for the adoption of this empirical approach and the use of Scrum. Scrum masters help remove impediments to the Scrum Team completing its work effectively. They help the Scrum Team become more able to deliver valuable, usable Done Increments and are accountable for the team’s effectiveness.
The Developers are committed to creating any aspect of a usable Increment each Sprint. They are accountable for the Sprint backlog, adhering to the Definition of Done and adapting their Sprint Backlog daily towards achieving the Sprint Goal.
The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. They are accountable for the Product Backlog, which contains the valuable work the Developers may complete to deliver the product.
Things will change as development proceeds. As the team has incomplete knowledge of what is needed and how to build the product at the start, this is natural and normal.
Scrum provides a set of rules and recommendations to help manage this change and turn it into an advantage to deliver a product of the highest possible value.
What You Need To Know About Scrum
Scrum is a problem-finding framework. It solves only a small subset of the problems you will encounter as you develop a complex product. When doing complex work, much is unknown; many things will change, and there is often no single and straightforward answer about what to do and how to do it. Scrum sets you up with a way of finding and dealing with the issues you will encounter. Scrum helps spotlight your biggest challenges, problems and risks that will prevent you from delivering a valuable product. Scrum is designed to help you discover and deal with these issues early and often. This, in turn, allows you to lower risk and start eliminating problems early and often, rather than later, when time is more limited and pressure is higher.
The rules of Scrum act like a safety bumper, protecting you from significant risks as you do complex work. Scrum requires teams to work in short cycles (Sprints) and reevaluate and replan each Sprint to take advantage of new insights and learnings.
Scrum is simple to learn, but challenging to master. The analogy of Chess can be used to explain this concept better. The rules of chess are simple to learn; however, playing Chess to a high level is incredibly difficult and takes a lifetime to master. Scrum is similar.
Scrum is a different way of working and requires people to let go of some of the established “best practices” and ways of working from the past. This cannot be easy. The challenge of changing people’s beliefs and long-established habits should not be underestimated.
Scrum requires a Done & Usable Increment by the end of each Sprint. This may not be easy to achieve for new Scrum Teams. That is natural, normal and the whole point! By discovering the difficulties early, we can work to remove them.
It is better to discover issues early in the development effort, so there is time and options available to deal with them. Persevere, keep going and keep improving. This is the whole point of Scrum! Scrum is about learning how to get Done earlier and exposing the issues that prevent us from doing this, so we can collaborate to overcome them. It is not intended to be easy or not to require any changes other than the introduction of Scrum to resolve long-lived issues.
Producing Done Increments each Sprint enables agility, maximises options, limits waste, lowers risk and allows a Scrum Team to deliver value early and often. All of this is critical to success when doing complex work.
Scrum is deliberately lightweight and incomplete. It will not be enough to enable you to build complex products. As you proceed, you will need to add appropriate practices and tools to create your own process. Scrum is a starting point and not the result. Use Scrum to create, adapt and improve your process and working methods.
History Of Scrum
Scrum was first implemented in 1993 by Jeff Sutherland and others at the Easel Corporation. They drew concepts from the Harvard Business Review (HBR) article, The New New Product Development Game2 (Hirotaka Takeuchi and Ikujiro Nonaka. 1986). The article describes how companies, including Honda, Canon, and Fuji-Xerox, had generated superior results using a scalable, team-based technique in product development.
Self-organising, cross-functional teams were empowered to work towards achieving goals. Although the examples cited in the article were outside the software industry, they inspired those building software to experiment with the same concepts to see whether they could help in similar ways in this domain.
Ken Schwaber and Jeff Sutherland worked on Scrum until 1995, when they co-presented Scrum at the OOPSLA Conference. This presentation detailed the learning that Ken and Jeff gained over the previous few years and made public the first formal definition of Scrum.
In the years following its presentation at the OOPSLA Conference, many people began to adopt and use Scrum. As the volume of people using it increased, so did the confusion about what Scrum was. As a result, Ken and Jeff collaborated to produce the Scrum Guide; the first version was released in 2010. The Scrum Guide documents Scrum as developed, evolved, and sustained for 20-plus years by Jeff Sutherland and Ken Schwaber.
Millions of people worldwide now use Scrum to develop products & services, and the usage of Scrum continues to increase. The most recent major trend has seen Scrum grow beyond its software development origins. In my public Scrum training courses, it is now common for up to 50% of the people to come with interests beyond software, including, but not limited to, Pharmaceuticals, Construction, HR, and Marketing. The world is becoming more complex, and more people are turning to Scrum to help them control complex work and deliver value.
The latest update to the Scrum Guide in November 2020 reflected this trend by seeking to simplify Scrum for people outside of software. Language tying Scrum to I.T. was removed. Other concepts were simplified, and many practices were removed to make Scrum even more of a framework than ever before.
Complexity & Empiricism
Before Scrum & Agile became widespread, traditional approaches to software development utilised a predictive method. This was based on the belief/assumption that the work could be effectively planned and change could be controlled. This is not the case with complex work; most software development work falls into the complex domain.
Complexity refers to software development projects being often unpredictable and involving multiple interdependent variables, making it difficult to plan and execute linearly or sequentially. In complex environments, the best approach is to embrace uncertainty and adapt to changing circumstances as they arise. This contrasts traditional "waterfall" predictive project management approaches, which assume that requirements can be fully defined upfront and that the project can be planned accurately and executed linearly. When using the "waterfall" approach in complex environments, plans and budgets frequently overrun, quality may decline as pressure increases, and as a result, expectations are often not met. The consequence is typically a loss of trust and money and damaged relationships. Products fail, and organisations may fail with them.
Predictive approaches do not offer the best chance of success when doing complex work, such as work where outputs, outcomes and challenges cannot be well predicted and fully understood beforehand. In these environments, we cannot standardise and rely on best practices. Each challenge we face is unique and requires its own new and unique solution.
Empiricism refers to the idea that knowledge comes from experience and observation rather than theory or speculation. Agile teams use an empirical process control approach to manage work. This involves raising transparency on the actual state of the environment and progress, and then regularly inspecting and adapting based on feedback and observations. It uses data and metrics to guide decision-making and measure progress wherever possible.
Scrum utilises this empirical approach to complex work to help maximise value delivery. It directs us to develop our product iteratively and incrementally using small, self-managing, cross-functional teams. We learn as we move forward, and re-plan and adapt as we discover new insights. We accept that in advance, it is not possible to know everything about what our customers want, what technical challenges we will encounter, and how people will work together. As a result, any plans we make are based on incomplete data and are likely less reliable. Plans will need to change and improve over time as more becomes known.
As more about our product domain becomes known, our ability to make accurate predictions may increase. Knowledge comes from experience; the only way to get experience is to build the product, deliver it to customers, and inspect the results. Scrum creates an environment where these activities occur by design.
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
– The Scrum Guide3
Scrum Team
The fundamental organisational unit of Scrum is the Scrum Team. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
The Scrum Team is small enough to remain Agile and large enough to complete significant work within a Sprint, typically ten or fewer people. In general, smaller teams communicate better and are more productive.
Whilst small Scrum Teams are desirable, they must be large enough to ensure enough shared skills to develop the product without depending on other teams.
Scrum Teams with stable membership will further optimise efficiency. Forming or reforming Scrum Teams consumes resources and reduces effectiveness in most cases.
Ideally, Scrum Team members will be dedicated to one team. This will reduce multi-tasking and allow people to increase focus and commitment, leading to reduced waste and better outcomes. It is desirable for Scrum Team members to have input into the design and structure of the team. This encourages self-management from the start and may increase ownership and motivation.
Why Do We Need a Scrum Team?
Scrum requires a cross-functional, self-managing Scrum Team to produce usable Done Increments each Sprint. For many traditional organisations, enabling this is a significant challenge.
In many larger, traditional organisations, people are organised into teams with specialist skill sets. Work is managed and handed off to these specialist teams. Each team has its own culture, practices, standards and priorities. These teams will work on many different initiatives at the same time. The volume of work will mean that management of the work and the people is essential.
Here are some of the challenges that are inherent in this traditional approach:
Significant dependencies will arise between teams, which will lead to delays.
Specialist teams will seek to optimise their work, which may lead to unnecessary delays at the product level.
Specialist teams will manage large work volumes and regularly shift priorities. This is another form of waste.
It will be challenging for the people in these teams to feel connected to the end-user/customer and see the value of their work when it is only a tiny part of a more extensive product.
When work for one product has been spread to many specialist teams, it will be hard to understand the actual current state of the product.
Full testing of the product will be impossible until the work of these teams has been integrated into a cohesive product.
Where issues cross-cut several specialist teams, communication may be challenging as people who are unfamiliar with each other and have different goals, motivations, and interests will need to find ways to collaborate. When clear communication is not achieved, an “us vs them” blame culture may result.
Change will be difficult under these conditions. A change in direction for the product may lead to significant waste and frustration as work is abandoned by some teams working ahead of others.
Ultimately, transparency will be low, risk will be high, and change will be difficult. The realisation of value will be delayed. Developing products under these conditions is difficult and prone to failure.
Scrum requires a different approach to mitigate these issues. In Scrum, we have Developers with the skills that would have been present in each of these specialist teams. We develop the product iteratively and incrementally rather than as a single large entity. The Developers are empowered to manage their work and take responsibility for developing Done Increments each Sprint.
This is intended to enable the following benefits:
Reduced risk through increased transparency and real inspectable progress at regular intervals, giving a clearer picture of what is going on and the current state of the product. Problems can be found earlier and then eliminated over time.
Higher quality through regular testing and validation of the product.
Earlier value delivery is possible as we can release Increments when it makes sense for the customer and the organisation.
Increased agility as we are working on smaller pieces, which means the cost of changing work not started will be lower. This is vital in complex environments where change is inevitable.
Less management of work and people will be required as the volume of work in progress will be lower and, therefore, manageable at a lower cost.
Team members will be closer to the user, customer and stakeholders, and have more access to the big picture of the product. This can help to keep motivation levels high as people stay connected to the purpose behind their work.
Fewer delays as the scope of work is smaller inside a Sprint. If one person gets stuck and needs help from another specialist, the other person will be present in the team and available to deal with the issue sooner and without a formal handoff.
Increased and regular collaboration means problems can be solved faster. When we hit a situation that requires three people with different skills, it will be faster for them to get together to address the issue. They will already be team members, so they will have relationships and understanding. Their responsibility is joint and shared – develop a Done Increment each Sprint.
Scrum is helping us simplify some elements of complex product development by lowering the volume of people involved, reducing the importance of work in progress, and ensuring we have the skills and experience we may need available at all times inside the Scrum Team. The result is fewer dependencies and risks. The benefit is increased motivation and agility.
The changes needed inside a traditional organisation to create and support cross-functional, self-managing teams may be significant. The Scrum Master will support this transition, which may take time and effort. It requires people to change their identities and ways of working. Do not underestimate the challenge that this may bring. Using Scrum and an empirical approach comes with a short-term cost if it is new to the people involved.
As an aside, it is possible to build a product using Scrum and many specialist teams. This is a scaling topic and will be covered later.
Product Owner
The Product Owner is one of the three accountabilities inside a Scrum Team. One person holds this accountability. They are accountable for maximising the value of the product resulting from the work of the Scrum Team. They ensure the Scrum Team is building the right things in the correct order. How this is carried out will vary widely in practice.
The Product Owner is accountable for effectively managing the Product Backlog, an evolving list of valuable improvements for the product. Management of the Product Backlog includes:
Developing and explicitly communicating the Product Goal and the long-term objective for the product.
Creating and communicating Product Backlog items.
Ordering Product Backlog items to ensure the most critical work is completed first.
Ensuring that the Product Backlog is transparent, visible and understood by the Scrum Team and stakeholders.
The Product Owners may do all those things or delegate responsibility to others (typically Developers in the Scrum Team). Regardless of who manages the Product Backlog’s day-to-day management, the Product Owner remains accountable.
The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. The value the Product Owner has helped create is made accurate and transparent via the Increment. For Scrum to succeed and deliver value efficiently, the organisation must recognise, respect and support the Product Owner.
As an organisation develops trust in the empirical approach that Scrum brings, Product Owners may become like a “mini CEO” for the product. They will be empowered to make tactical, near real-time decisions on the product’s future direction based on data and insights that emerge from the Scrum Team as they do their work.
The product owner is responsible for product strategy. They are not, however, responsible for the development process and how the work gets Done. The Developers take on responsibility for this.
Although not prescribed by Scrum specifically, effective Product Owners typically exhibit these characteristics:
They define and communicate the goal and strategy of the product they wish to build.
They have a good understanding of customers, users, the business, the marketplace, the competition, and future trends for the product.
They are effective communicators and facilitators, enabling stakeholders to make decisions despite limited data or information.
They are decision-makers who can say no or not now and explain why they have reached a decision.
Being a Product Owner can be challenging. The team may build the wrong thing if the Product Owner makes a bad decision. Significant waste will result. Product Owners need support from the Scrum Team and stakeholders to succeed. Making information and decisions transparent, combined with frequent inspection and adaptation around options and decisions, will increase the probability of success.
Although it is somewhat oversimplified, it can be helpful to think of the Product Owner as accountable for the “what”. They ultimately decide on what product is developed in the Scrum Team.
Why Do We Need a Product Owner?
Product Owner accountability was added to Scrum to respond to the traditional product management approach, which was problematic but typical in many organisations. Such organisations relied on a hierarchical command structure to solve problems and make decisions. Despite agility being around for decades now, many organisations still do this! This traditional approach caused many issues, such as late, low-value, low-quality projects and product deliveries.
Here is how product-related issues and decisions were made in a pre-Agile organisation. First, the team building the product is told what to do and how to do it by management external to the team. The belief is that those in management roles and further up the hierarchy will make the best decisions, leading to the best product.
When a problem is encountered, or a decision is needed, it is escalated up the management chain to the appropriate level in the hierarchy. The more experienced and trusted people make the decision. This is typically a committee of managers from different departments across an organisation for significant issues or decisions. This committee is expected to review the information presented to them and send a decision back to the team.
This sounds sensible in theory. However, in practice, this typically leads to delays in decision-making and undesirable outcomes. The Scrum Team must wait for the committee to meet and decide what to do. The committee often lacks the complete information to choose, so they defer the decision and request more information from the team. This pattern repeats, but the time it takes is rarely reflected in the team’s plan. The deadline they are working towards becomes increasingly unlikely to be met.
Things then get worse. The product team parks the issue and moves on to working on something else, which is often lower value. Any decisions the team make on behalf of the committee may be reversed at any time by the committee. The team will be blamed for any wrong choices or waste that this creates. The pattern repeats. An issue is raised. No clear decision is made. The team is starved of decisions, leaving the valuable work and moving on to lower-value work to keep busy. The issues and unmade decisions pile up and compound.
The problem is further compounded as the more senior the committee, the less often they will meet. So, the more influential the issue and decision, the more significant the delay. It is difficult for a committee to reach a consensus with multi-dimensional issues that crosscut the interests of different departments. Each committee manager also has unique motivations, interests and loyalties. Committee members do not want to be responsible for making incorrect, hard-to-reverse decisions based on incomplete information. So, the committee defers the decisions, requesting additional information. However, the information is always incomplete and subject to change in complex environments. We are caught in a vicious circle!
The result of all of this is:
Big decisions get delayed.
Work gets delayed. Deadlines are missed. Promises are broken.
Customers are unhappy.
Management is unhappy.
The committee is unhappy.
Management and the committee blame the Scrum Team.
The Scrum Team is frustrated, demotivated and unhappy. This is reflected in the future work of the team.
This is the Decision/Issues/Information/Committee Circle Of Doom or the DIICC of Doom. Don’t get caught in a DIICC of Doom!
The Product Owner is Scrum’s simple answer to the DIICC of Doom. Scrum requires one person to occupy the Product Owner accountability. They may (and should) consult others, but ultimately, this person is accountable for maximising the value of the product resulting from the work of the Scrum Team.
In complex environments with limited information, it is often better to make a decision later proved wrong and reversed rather than make no decision at all while waiting for perfect information that may never arrive.
Product Owners build trust with those around them by facilitating the decision-making process with a broad group of stakeholders despite incomplete information.
Product Owners are accountable for effectively managing a Product Backlog that makes decisions transparent. They work with the rest of the Scrum Team to deliver Done Increments of value each Sprint.
Developers support the Product Owner by building products to minimise the cost of changing direction when new information emerges and decisions need to change.
So, the Product Owner’s accountability is critical and should be filled by someone with the requisite experience, knowledge, support and empowerment. This will allow for better decision-making based on learning and understanding. Where no such person exists, the organisation needs to empower and support someone to grow into the accountability and accept and manage the increased risk this will bring.
Ultimately, the Product Owner becomes the “mini CEO” for the product and helps the Scrum Team maximise their work’s value.
Scrum Master
The Scrum Master is one of the three accountabilities in a Scrum Team. They are accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice within the Scrum Team and the broader organisation.
The Scrum Master is accountable for the Scrum Teams effectiveness. They help create the conditions for effective delivery through facilitation, coaching, teaching and mentoring.
Facilitation includes more than just facilitating the Scrum events. The Scrum Master facilitates the successful development of the product. They facilitate transparent decision-making. They facilitate increased quality, collaboration, and an empirical approach to managing the work.
Scrum Masters are change agents helping people and organisations to adopt Scrum and take an empirical approach. They support the adoption and use of Scrum in organisational environments where it is not yet fully adopted and understood.
Scrum Masters are true leaders. They provide delivery leadership while acting as a servant who helps remove impediments to the Scrum Teams progress. They do whatever is in their power to help the Developers, Product Owner, and the organisation succeed.
The Scrum Master helps those outside the Scrum Team understand Scrum and which of their interactions with the Scrum Team are helpful and which aren’t. They help everyone change these interactions to maximise the value created by the Scrum Team.
The Scrum Master serves the Scrum Team in several ways including, but not limited to:
Coaching the team in Scrum, self-management and cross-functionality.
Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
Causing the removal of impediments to the Scrum Teams progress.
Ensuring that all Scrum events occur and are positive, productive, and kept within the timebox.
The Scrum Master serves the Product Owner in several ways, including but not limited to:
Helping find techniques for effective Product Goal definition and Product Backlog management.
Helping the Scrum Team understand the need for clear and concise Product Backlog items.
Helping establish empirical product planning for a complex environment.
Facilitating stakeholder collaboration as requested or needed.
The Scrum Master serves the organisation in several ways, including but not limited to:
Leading, training, and coaching the organisation in its Scrum adoption.
Planning and advising Scrum implementations within the organisation.
Helping employees and stakeholders understand and enact an empirical approach for complex work.
Removing barriers between stakeholders and Scrum Teams.
Great Scrum Masters can come from any background or discipline. Having technical knowledge can be advantageous, but what matters most is their ability to help the people around them take an empirical approach and deliver value.
The Scrum Master is not a Project Manager. They are not the manager of the Product Owner or the Developers. They do not get to tell the Developers how to develop a Done Increment best. They do not get to say to the Product Owner what is valuable. They do not assume the other accountabilities when things go wrong.
The Scrum Master may or may not be a full-time job. In environments where Scrum is new, or when a new team is developing a new product, the demands on the Scrum Master may be high, requiring someone to fulfil the accountability full time. In more mature environments, the markets may be less, and the Scrum Master may be able to work with more than one Scrum Team or take on additional responsibilities.
Although the rules of Scrum permit it, it is often bad practice for the Scrum Master to hold one of the other Scrum accountabilities simultaneously. Too much accountability in one person’s hands can lead to conflict and may result in them neglecting essential aspects. There will be an impact on the rest of the Scrum Team, which may lead to a less valuable product being delivered. Sometimes, it is unavoidable, which is why Scrum permits it. Still, you should think carefully about sharing the Scrum accountabilities, especially when people are new to Scrum and demand for the Scrum Master will be high.
The Scrum Master accountability can be rotated between people, but this is rarely good practice. If someone takes on the accountability temporarily, they are unlikely to have the time or motivation to address the more considerable impediments that the Scrum Team may face. Learning to perform as a Scrum Master and help the Scrum Team will take time, so having someone consistently fulfilling the accountability is usually advisable.
Although it is somewhat oversimplified, it can be helpful to think of the Scrum Master as being accountable for the “who”. They are accountable for how people use Scrum, interact, and collaborate to deliver value.
Why Do We Need a Scrum Master?
Scrum can be a dramatic change in approach for organisations that are new to it. It is a change from a predictive to an empirical approach to work. From a traditional way of developing products to an Agile approach. This can be a significant change for organisations working more conventionally for a long time.
The impact and cost of this change should not be underestimated. People may be comfortable with the status quo and not accept the need to change the approach. People may resist and actively work to prevent the change, significantly if it impacts their identity, values, and beliefs and takes them out of their comfort zone. Change is often necessary, but still difficult.
The Scrum Master is a change agent helping people and the organisation to adopt Scrum and take an empirical approach. They support the adoption and use of Scrum in organisational environments where it is not yet fully adopted and understood. As this may be a considerable challenge, Scrum Master accountability is necessary to support the change. Having someone assume this accountability will be vital to its successful adoption.
The Scrum Master promotes and supports this change over the long term. They will need a mandate and ongoing support from management and leadership to succeed. Patience will be necessary as the change can take significant time and effort. This change will not be their top priority for many people in the organisation.
Once Scrum is understood and adopted, there will be new challenges for the Scrum Master to face. Change can and will happen even when things are going well, and the organisation may regress to an earlier state. Changes in personnel over time may make this even more likely. This is why Scrum Master accountability does not go away over time. A Scrum Master is always required in the Scrum Team.
Developers
A Developer is one of the three accountabilities inside a Scrum Team. The Developer team is made up of the people who are doing the day-to-day work of creating the product. They collaborate closely to create value as early as possible. They are collectively committed to creating all aspects of a usable Increment each Sprint.
Developers are always accountable for the following:
Creating a plan for the Sprint, the Sprint Backlog.
Instilling quality by adhering to a Definition of Done.
Adapting their plan each day toward the Sprint Goal.
Holding each other accountable as professionals.
They are accountable for forecasting the work to select for a Sprint and sizing items in the Product Backlog.
The term Developer is explicitly used to be considered inclusive rather than exclusive. Anyone using Scrum to develop something of value can consider themselves a Developer. A Developer is a person inside the Scrum Team who develops the product, whatever that product may be. It may help to think of “development” as “work” because the Developers carry out the work to produce the Increment.
Although it is somewhat of an oversimplification, it can be helpful to think of the Developers as being accountable for the “how”. They have the ultimate accountability in the Scrum Team around how the product is developed.
Stakeholders
Scrum uses the term stakeholders as a catch-all term for people outside the Scrum Team who have an interest in the product. This may include users, customers, management, governance and anyone else. As Scrum is a simple framework, it does not seek to detail the different types of stakeholders you may work with to keep things simple.
