Inside the Scrum Team - Part 1 Written and Narrated by Peter Stevens Graphic and Video by Thierry DELESTRE
Peter Stevens: Welcome to Inside the Scrum Team.
In part one of this video, you'll discover how a Scrum Team interacts with the outside
world to create great products.
So here we go.
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 digital
transformation, healthcare, cybersecurity manufacturing, 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.
Scrum was modeled on patterns of successful product development.
So let's start here with the product.
The product might be something you'd put in a box, but it could also be something more
abstract, like a new store location or process improvement for your company.
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 elements.
Scrum calls this 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, or something you can test in real
life.
Most importantly, something the Scrum team can review together with its stakeholders.
The idea is to produce tangible results, every sprint.
You can produce increments more often even deploy them continuously, if that makes
sense and if your team has the technical excellence to do so.
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 the 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.
Stakeholders usually appreciate having a working increment frequently.
This virtually eliminates delivery risk and 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.
This is possible because each product increment works, it is done.
Done is a quality gate, nothing enters the product increment unless it is 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 usually never really ends.
The Definition of Done is often a simple checklist that covers both acceptance
criteria and quality control.
It ensures that the features from previous sprints still work,
and that the team maintains its quality standards.
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 towards 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.
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 as the
team gets larger, effectiveness usually declines and performance suffers.
Conversely, a small team may not have all the skills needed to build a product,
especially if someone goes on vacation gets sick or is otherwise unavailable.
Product Development in Scrum is a continuous cycle of generating ideas, creating new
product increments, collecting feedback and self improvement.
In Part Two, we'll zoom in on the Scrum Team to see how each member contributes to the
whole.
I hope this is useful to you!
(c) 2022 Peter B. Stevens Video and Text Licensed under Creative Commons CC-SA-ND
Peter Stevens: Welcome back to Inside the Scrum Team.
In Part One, 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, creating new product increments, collecting feedback, 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!
So let's look inside.
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?'
And 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 different priorities and other
things to do.
Committees can be notoriously slow at 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.
These decisions include sequencing, acceptance criteria, and whether to release
the product, continue development, or even abandon the effort.
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, continue, or abandon becomes a
business decision.
If the return on investment looks bad, the product owner is expected to pull the plug.
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 ensuring 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.
Traditionally, the Product Owner's mission has been summarized in three words:
Vision, focus and flow.
Scrum represents these concepts through the Product Goal, the Sprint Goal, and backlog
refinement.
Backlog refinement is the process of making the most important backlog items
transparent, visible, understood, and small.
Backlog items that are small enough to be completed in a sprint are considered ready.
The whole team is involved;
stakeholders can be invited;
and the Product Owner is accountable.
The Product Owner defines work for the team using the Product Backlog.
The Product Goal describes the 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 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 product 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.
The 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 work 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.
Sometimes more than one Scrum team will be involved 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.
Direct communication usually leads to the clearest understanding of the users 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 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 the product.
The Team also refines the backlog frequently and can invite stakeholders to support them.
The Scrum Master is accountable for the Scrum Team's effectiveness.
He does this by enabling the Scrum Team to improve his 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 continuously improving.
So the Scrum master is continuously helping the team and the organization to find better
ways of doing what they do.
Among all the metaphors for the Scrum Master, I find 'Voice of the Common Sense'
to be the most compelling.
Common sense is often not 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.
Anything that slows the team down is considered an impediment.
Most impediments arise within the Scrum Team.
The Scrum Master may not resolve these 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 these 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 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.
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 each 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.
The goal of Scrum is to enable you to create better results sooner.
A good Scrum Team is both effective and a joy to work in.
So that's a look Inside the Scrum Team. I hope this is useful to you