Inside the Scrum Team – Part 2

Update: Watch the final version and download materials at https://bit.ly/insideScrum

Yesterday, I recorded the sound track to go with the video version of the Inside the Scrum Team info-graphic! Here is the script for Part 2, which is is about how the Scrum Team interacts with each other so you can create great products.

My goal is that anyone will be able to use these videos to train and share Scrum. They strives to be up to date and correct, while giving the flavor of a good Scrum implementation. Aside from author credits, there is no branding, and both the graphic and the video are reusable under a Creative Commons license.

The video will premier on October at the Regional Scrum Gathering in Sri Lanka. Follow me on Linked In for updates, and please support this video by contributing to my gofundme to cover production costs.

Script for Part 2 – Interactions Inside the Team

Hi! In Part 1, we looked at how the Scrum Team interacts with the outside world and discovered how product development in Scrum is a continuous cycle of generating ideas, collecting feedback, creating new product increments, and self-improvement.

With this video, you will explore how Scrum guides interactions and relationships within the Scrum Team, again so you can apply Scrum effectively in real life. Let’s look at what happens inside…

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.

Product Owner and stakeholders

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!

Product Owner only

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!