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.
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…
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.
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?
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.
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 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.
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.
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.
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.
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.
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!
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!
|cookielawinfo-checkbox-advertisement||1 year||Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .|
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
|mailchimp_landing_site||1 month||The cookie is set by MailChimp to record which page the user first visited.|
|CONSENT||2 years||YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.|
|_ga||2 years||The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.|
|_gat_gtag_UA_42152348_1||1 minute||Set by Google to distinguish users.|
|_gcl_au||3 months||Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.|
|_gid||1 day||Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.|
|NID||6 months||NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.|
|test_cookie||15 minutes||The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.|
|VISITOR_INFO1_LIVE||5 months 27 days||A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.|
|YSC||session||YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.|
|yt-remote-connected-devices||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|yt-remote-device-id||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|COMPASS||1 hour||No description|
|cookies.js||session||No description available.|
|S||1 hour||No description available.|