The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
Scrum has only three roles: the Product Owner, the Scrum Master, and the Team. The Scrum Master serves as a facilitator for both the Product Owner and the team. The Scrum Master has no authority within the team (thus couldn’t also be the Product Owner!) and may never commit to work on behalf of the team. Likewise, the Scrum Master also is not a co-ordinator, because (by definition) self-organizing teams should co-ordinate directly with other teams, departments, and other external entities.
The best Scrum Masters are the types of people who feel as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. Traditional project managers don’t always make great Scrum Masters, especially if they’ve previously managed the same team members. One problem I hear about from recovering project managers is that the teams still look to them for direct instructions rather than stepping up to team self organization. “Self organize, dammit!” But there are exceptions; some amazing Scrum Masters were once project managers. Perhaps it’s best to let the team and Product Owner decide who should be their Scrum Master.
What does a Scrum Master do? The Scrum Master removes any impediments that obstruct a team’s pursuit of its sprint goals. If developers don’t have a good sense of what each other are doing, the Scrum Master sets up a physical taskboard and shows the team how to use it. If developers aren’t colocated, the Scrum Master ensures that they have team room. If outsiders interrupt the team, the Scrum Master must redirect them to the Product Owner. If the team has not learned how to develop a potentially shippable product increment every Sprint, the Scrum Master teaches them Test Driven Development (TDD), or finds people who can teach them. If the existing code is so bad that it slows down new development, the Scrum Master helps the team learn how to pay off technical debt incrementally.
As the team grows into a self-managing entity, the Scrum Master’s role shifts toward the organizational impediments, issues caused by the outer organization. If the company still has a “business side” and an “IT side”, the Scrum Master works to make each team cross-functional. If the team depends on outsiders, the Scrum Master must help transform the organization to use cross-component feature teams. If “Human Resources” policies (e.g. performance appraisals and job titles) interfere with intrinsic motivation and teamwork, the Scrum Master must educate the business about the harm caused by those policies (incidentally, agile advocates don’t refer to humans as “resources”).
Scrum Masters are full-time transformation agents, but they do not push for change. What do people do when you push them? They push back. Instead, effective Scrum Masters promote transformation through illumination and invitation. Conversations with executives don’t work without a background of relatedness. In established organizations, improvements come in fits and starts. Sometimes it seems like nothing is changing, then the organization has a breakthrough right when we were about to give up. This can be emotionally taxing, so I advise Scrum Masters to connect with a community of Agilists. Product development is mostly about knowledge creation and collaboration, but most large organizations would require fundamental changes before they could be called learning organizations. Skilled Scrum Masters read books about facilitation, persuasion, mindfulness, and what Marshall Rosenberg called “Nonviolent Communication.”
To understand the full scope of the Scrum Master role, see the Scrum Master checklist, which is referenced by several bestselling Agile books. The Scrum Master Checklist examines four questions effective Scrum Masters consider each day: How is my Team doing? How is my Product Owner doing? How are our technical practices? How is the larger organization doing?
About The Author
ExamplesThe ScrumMaster Role
Posted by admin under Scrum Basics
There are three roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team.
In Scrum, the Product Owner is the one person responsible for a project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining work in the Product Backlog, and prioritizing it based on business value. Of course, he or she must also consider the stakeholders and the team. As such, the Product Owner must be available to the team to answer questions and deliver direction.
This combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Scrum values self-organization and, as a result, the Product Owner must respect the team’s ability to create its own plan of action. This means that a Product Owner is forbidden to give the team more work in the middle of the sprint. Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner is discouraged from altering the sprint until the next sprint planning meeting. However, the Product Owner may cancel a Sprint when necessary. One Product Owner I know cancels Sprints once or twice per year tops.
It is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions—that the team might not appreciate—during sprint planning. However, the Product Owner is the one person who must face the music if the project crashes and burns. Therefore, he or she must aggressively determine which features of a product are most important, when they are developed, etc. Just as the development team must produce the negotiated work for the Product Owner, the Product Owner must deliver the product to the customer.
The responsibilities of the Product Owner are also described about halfway through this video module:
Posted by admin under Scrum Basics
In Scrum, the product backlog is the single most important artifact. The product backlog is, in essence, an incredibly detailed analysis document, which outlines every requirement for a system, project, or product. In simpler terms, it could be described as a comprehensive to-do list, expressed in priority order based on the business value each piece of work will generate. Philosophically, the scrum backlog is the engine of the business; it breaks the big-picture story down into manageable increments of work called Product Backlog Items (PBIs).
When the sprint planning meeting occurs, the Scrum team converses with the Product Owner to determine what work they will tackle in the impending iteration. At this time, the Product Owner imports PBIs from the into the sprint backlog.
Now, you may be wondering what a backlog looks like. The answer to that rests on whether a Scrum team uses manual agile or an agile tool to track progress. With manual agile, a team would create a physical manifestation of the backlog, using a dry erase board, Post It notes, or a taskboard. This is ideal for teams that work in closely proximity, whether the same office or room. In this setting, every team member has easy access to the product backlog, the sprint backlog, and the status of its stories; they can simply get up from their desks and walk over to them.
When Scrum teams are not collocated, however, they often require a tool to help them all stay on the same page. There are numerous tools designed to bring geographically distributed teams together using a virtual taskboard. Danube publishes ScrumWorks® Pro, a Scrum management tool that gives users a Web-based task management interface that mimics the look and feel of a physical taskboard. The tool also offers more detailed views of the product and sprint backlogs, organized in adjacent panes and easily modified with drag-and-drop prioritization.
Although it is the team’s responsibility for completing the work, the Product Owner is the only one who can prioritize work in the scrum backlog or, after negotiating with the team, add work to the sprint backlog.Tags: backlog items, scrum backlog, scrum backlog items, Scrum Methodology, scrum PBIs
Posted by admin under Scrum Basics
While backlog refinement (also called grooming) was not originally a formal meeting in the Scrum framework, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. As with Scrum’s other meetings, the grooming should take place at the same time and place and for the same duration each sprint.
Everyone attends the backlog refinement meeting: the team, the Product Owner, and the ScrumMaster. During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. Why is this helpful? Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.backlog grooming, scrum backlog, scrum backlog grooming, Scrum Methodology
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013