About Scrum
Scrum is a simple, team-based framework for solving complex problems. If you only remember one thing about Scrum, remember this: “Inspect and Adapt at regular intervals… and tell yourself the truth.”
Scrum was created for software development, where it is widely used, but today it finds application in many other complex domains, like corporate transformation, hardware development, and education, to name just a few.
The definitive description is found in the Scrum Guide. This is both the reference and the place to start. With this video, you can discover how Scrum guides interactions and relationships with the Scrum Team, so you can apply Scrum effectively in real life.
Product Increment
Scrum was modeled on patterns of successful product development, so let’s start here: The product.
How it works
Scrum works in short iterations, called sprints. At least once per sprint, the Scrum Team produces a new version of the product with a few new or upgraded features.
This is called the “Product Increment,” but I like to call this a tangible result: Each Sprint produces a tangible result that supports the overall goal: Something you can use, something you could sell, something you can test in real life; most importantly, something the Scrum Team can review together with its stakeholders.
Whether your team is developing software or doing something else, the idea is to produce tangible results, every sprint. You can produce increments more often, even deploy them continuously, if that makes sense and your team has the technical excellence to do it.
Stakeholders
A product is built for its stakeholders, and most development efforts have many of them.
Two of the most important are the users, that is the people who will actually use the product, and customers, the people or entities who actually pay for the product, but many other people could be involved. Without stakeholders there would be no product!
Frequent Delivery
Stakeholders usually appreciate having a working increment frequently! This virtually eliminates Delivery Risk. Direct interaction with stakeholders builds trust and reduces Market Risk, that is, increases the likelihood that the product will be a success!
With a working product in hand, you can have good conversations about what you have, what changes are needed, and how best to move forward. You can also identify work to delay or skip entirely, saving both time and money.
Done
This is possible because each “Product Increment” works. It is “Done!”
“Done” is a quality gate: nothing enters the Product Increment unless it done. Every Scrum team has a definition of done, and it is applied to every feature and every increment.
The definition of Done does not address whether the product is complete or “finished.” As long as a product is viable, its development never really ends.
The Definition of Done is often a simple checklist that covers both acceptance criteria and quality control. It ensures that features from previous sprints still work and that the team maintains its quality standards.
The Scrum Team
The Scrum Team is accountable for creating a valuable, working product increment every sprint. Ideas come into the team, the product owner sequences them, and the Scrum Team commits to do its best to turn the most valuable of those ideas into a working solution by the end of the sprint.
Accountabilities define each member’s contribution to the overall result. Scrum forbids hierarchies or sub-teams within the Scrum Team. There is one team working toward a common goal.
The Scrum Team consists of Developers who are accountable for creating the increment, a Product Owner who is accountable that the increment is valuable, and a Scrum Master who is accountable that people can work and collaborate effectively.
A Cross-Functional Team
The Scrum Team solves the problem together. They organize and manage themselves. A Scrum Team is cross-functional, that is, it has all the skills and authority necessary to transform incoming “ideas” into something that is “done” and valuable. This includes making decisions about the product.
Typically, a Scrum Team has 10 people or less. The limit is not rigid, but if the team gets larger, effectiveness usually declines, and performance suffers! Conversely, a small team may not have all the skills needed to build the product, especially if someone goes on vacation, gets sick, or is otherwise unavailable.
Product development in Scrum is a continuous cycle of generating ideas, collecting feedback, creating new product increments, and self-improvement.
Now, let's zoom in on the Scrum Team to see how each member contributes to the whole.
Product Owner
Here is the product owner. She is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Her key question is ‘why?’ It shows up frequently, both in her conversations with the stakeholders and with the rest of the team.
Stakeholders are tremendous sources of ideas, know-how, feedback, validation, and priorities. The challenge is that stakeholders can be noisy, have differing priorities, and have other things to do. Committees can be notoriously slow in making decisions. Let’s call this the alignment problem!
Scrum solves the alignment problem by designating one person who is authorized to make decisions about the product: The Product Owner. Her decisions are visible in the content and sequencing of the Product Backlog and in the increments produced every Sprint.
Those decisions include Sequencing, Acceptance criteria, Release or Abandon.
The Product Owner can decide what will be done first and can have final say both on the definition of acceptance criteria and whether an item is done.
Since each increment is really done, whether to release or not becomes a business decision. And if the return on the investment will not be satisfactory, the Product Owner is expected to pull the emergency brake.
The product owner is often called the voice of the customer or stakeholder. Her primary focus is not simply on staying within the budget, but on achieving a good investment. She ensures that the sponsor’s money is well spent. How does she know? By having good conversations with stakeholders and getting good answers to the why-questions.
Vision, Focus and Flow
The Product Owner’s mission is often summarized in three words: Vision, Focus and Flow.
Vision: The long-term answer to the why question covers, what are we building? What are we not building? What impact or benefit should this product have on the company, its users, its customers, and the world?
Focus: Each sprint should be the best step forward to achieving the overall vision, given what is known today. Why these features? Why these acceptance criteria? And why do them now?
Refinement
Flow: The developers need work, and that work is represented in the Product Backlog. Product Backlog Items that are well understood and small enough to be completed in a sprint are considered ready.
Backlog Refinement is the process of making the most important Backlog Items transparent, visible, understood, and small. In other words: ready. The whole team is involved, stakeholders can be invited, and the product owner is accountable.
Product Goal, Backlog and Sprint Backlog
The Product Owner defines work for the team using the product backlog. The Product Goal describes a future state of the product. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
The Scrum Team takes on work through the Sprint Planning process, which addresses three questions: Why, What, and How.
Why – Why are we doing this sprint? The answer, called the Sprint Goal, is a business goal that represents the best step forward to achieve the product goal. It is not a stretch goal; the team believes that they can accomplish the Sprint Goal during the sprint.
What – What are we going to deliver this sprint? This is a list of backlog items that the team believes will enable them to achieve the sprint goal. I call this the forecast, and like the sprint goal, the team believes it can deliver the forecasted items.
How – How will we accomplish the sprint goal? This is an actionable plan for achieving the sprint goal. The Sprint Backlog consists of the Sprint Goal, the Forecast, and the Task Planning, but does not define who does which tasks when. Those decisions are taken by the Developers in the daily scrum.
What if your team has work to do that doesn’t support the current product goal? While existing products sometimes need maintenance, constantly changing priorities slow you down and can even put your investment at risk. The Product Owner is accountable for finding the right balance.
Developers
Developers create the product increment. They solve the problem and deliver the solution. Together they have all the skills needed to create the increment. Even though no one individual can do everything, together they are strong.
The key question for developers is “How?” The developers are self-organizing and self-managing. They make the forecast, plan their work, design the solution, and ensure the quality of their work. They are professionals who care about results.
The Developers are dedicated 100% to the project. If they worked on more than one project at a time, commitment to results and accountability would not be possible.
The skills needed depend on the problem to solve. For software products, this often includes user experience, analysis, design, engineering, and testing, and may involve multiple different technologies.
For organizational transformation, the skills may include coaching and facilitation, knowledge of the organization, authority to change the organizational structure, and access to senior leadership.
The Developers estimate the work because they do the work. Combining these estimates into schedules, release plans, and budgets is usually handled by the product owner.
Thanks to the transparency and tangible results created by Scrum, traditional command and control is no longer necessary to hold the team together. Scrum teams create better results faster using trust, transparency, and fast feedback.
Collaboration with other teams
Sometimes more than one scrum team will be working on the same product. Regardless of the number of teams involved, the responsibility for “how” stays with the developers. The Scrum Masters do not become intermediaries between developers, but rather facilitate and encourage direct communication between the experts involved.
Clear Line of Sight
Direct communication usually leads to the clearest understanding of the user’s needs, so Scrum ensures a clear line of sight from those doing the work to those benefiting from the work.
Communicating through intermediaries is error-prone and inefficient, so the agile manifesto recommends frequent collaboration. Nothing in Scrum prevents Developers from talking to directly to stakeholders when it is helpful to do so!
Each Sprint, the Scrum team holds a Sprint Review for its Stakeholders to demonstrate the latest increment, discuss what has been learned, and identify what changes are needed to the future version of product. The team also refines the backlog frequently and can invite stakeholders to support them.
Scrum Master
The Scrum Master is accountable for the Scrum Team’s effectiveness. He does this by enabling the Scrum Team to improve its practices and collaboration. He doesn’t tell people what to do, but rather coaches them to recognize, understand, and address issues as they arise.
A high-performance team is continually improving, so the Scrum Master is continually helping the Team and the organization to find better ways of doing what they do.
Of all the metaphors for the Scrum Master, I find “voice of the common sense” to be the most compelling. Common sense is often not be very common, so the Scrum Master helps the Developers, the Product Owner, and the organization to create a common understanding of how to work together effectively.
Impediments
Anything the slows the team down is considered an impediment. Most impediments arise within the Scrum Team.
The Scrum Master may not resolve those issues personally but is accountable that they are recognized and dealt with promptly. Both the daily scrum and the sprint retrospective are opportunities to identify and respond to impediments, but you can raise issues even sooner if that is helpful.
Some issues can be really difficult and require time, perseverance, and persuasiveness to fix. The Scrum Master will usually take the lead on such issues, so the Developers can focus on creating the product. I like to think of the Scrum Master as the team’s ambassador to the outside world. When the developers need outside help, the Scrum Master is usually most able to focus on the issue.
The Scrum Master is often called a change agent. Change is easiest when everyone wants to do it, so a good Scrum Master will ensure that everyone genuinely wants to improve, is willing to change for the better, and wants to do Scrum.
Your first impediments
A Scrum Team is a happy team. If your team is not happy doing Scrum, that is a warning sign that something is amiss. The goal is not to cram more work into the sprint, the goal is to produce more value, sooner. Listen to your team and address at least one concern, every sprint!
The first impediment that most Scrum Masters face is whether the team even has the necessary skills and authority. Can the Product Owner make decisions about the product? Are the developers dedicated 100%? And do they have all the skills needed to produce a working increment every sprint? Finally, as Scrum Master, do you have time and permission to work proactively on impediments, especially those originating outside the team?
After that, frequent sources of impediments include excessive pressure, multitasking, bugs, and dependencies. The best way to manage these issues is not to have them, so start working on them soon!
Summary
The goal of Scrum is to help you create better products, sooner. The Scrum Team is intended to be both effective and a joy to work in.
That’s a look inside the Scrum Team. I hope it is useful to you!
