Agile Forest

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In this post, part 2 of 5, we look at the roles and how they have adapted, or not, over the years.

There are three defined roles for Scrum – the Product Owner, the Scrum Master and the Team. The links from 2003 for roles were dead but I think we can safely assume there were three roles back then.

Product Owner

In the 2007 pdf we have the Product Owner defined as:

The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting product. The Product Owner achieves initial and on-going funding for the project by creating the project’s initial overall requirements, return on investment objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration. The Product Owner is responsible for the success of the product.

In both March 2007 and March 2009 the Product Owner definition was:

The Product Owner has the following responsibilities.

• Define the features of the product;

• Decide on release date and content;

• Be responsible for the profitability of the product (ROI);

• Prioritize features according to market value;

• Adjust features and priority every 30 days, as needed; and

• Accept or reject work results.

The product owner is responsible for the first of the three Scrum ceremonies: Scrum Planning.

Within scrum.org the definition is now:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Ensuring the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

 The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says. 

The ScrumAlliance definition of the moment is sparse with:

Product owner: responsible for the business value of the project 

Product Owner results and opinion

• Aside from the ScrumAlliance’s less then detailed overview there can easily be seen a small transition of improvement of understanding of the role over time. Note how between the 2007 pdf and future content the Product Owner no longer became a person who has financial accountability. Basically the “Sponsor” part of the role was removed and the role then became a glorified Subject Matter Expert. No other role was created for the elusive person who had money, apparently they have no involvement in the project. I do like the concept of someone being accountable for the “product” but this is still a poor substitute for a real customer.
• How does a Product Owner know that the features will result in market value? Is it an instinctual activity? Do they do market research? These are questions that I do not believe the Scrum method adequately covers. This is likely why other methods or techniques such as Lean Startup have grown in support.
• Prioritisation evolved over time to be done as needed, which is a welcomed change.
• I do like how the current scrum.org definition clarified accountability versus responsibility.
• The scrum.org details on the Product Owner being a single, highly empowered person is also a welcomed clarification – but it does raise the point that this assumes teams work on one and only ever one product. The reality is that many maintenance, or Business As Usual teams support multiple products and whilst it is nice and warm and fuzzy to have a prioritized backlog from a Product Owner for each product being supported it still doesn’t help the team understand competing factors within the same organisation. Kanban does provide some explanations of how to handle this problem but  it certainly isn’t a part of any introductory readings.
• It is interesting to see that the “accept or reject the work results” responsibility was added mid evolution and is now removed again. Who is responsible for this if the Product Owner is no longer?
• I do have a question for the ScrumAlliance agilists – who is responsible for the quality of the Product? If the Product Owner is responsible for the business value, shouldn’t they also be accountable for the quality – after all, almost always when teams get pushed to deliver by a particular date it is quality that the Product Owner chooses to downgrade (at the future cost of maintenance and technical debt).

Scrum Master

In the 2007 pdf we have the Scrum Master defined as:

The ScrumMaster is responsible for the Scrum process, for teaching it to everyone involved in the project, for implementing it so it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows its rules and practices.

In March 2007 the Scrum Master definition was:

The ScrumMaster has three primary responsibilities in addition to leading the Daily Scrum meeting:

1. The ScrumMaster needs to know what tasks have been completed, what tasks have started, any new tasks that have been discovered, and any estimates that may have changed. This makes it possible to update the Burndown Chart which shows the cumulative work remaining day by day. The ScrumMaster must also look carefully at the number of open tasks in progress. Work in progress needs to be minimized to achieve lean productivity gains.
2. The ScrumMaster needs to surface dependencies and blocks which are impediments to the Scrum. They need to be prioritized and tracked. A remediation plan needs to be implemented for impediments in priority order. Some can be resolved with the team, some can be resolved across teams, and others will need management involvement as they may be company issues that block all teams from achieving their production capacity. For example, a telecom company recently implemented Scrum and found eighteen items on their impediment list, only two of which were directly related to Scrum teams. The others were company issues that needed management attention.
3. Last but not least, the ScrumMaster may notice personal problems or conflicts within the Scrum that need resolution. These need to be clarified by the ScrumMaster and be resolved by dialogue within the team, or the ScrumMaster may need help from management or the Human Resources. Certified ScrumMaster James Coplien developed over 200 case studies of notable projects while working at ATT Bell Labs. He reports that over 50% of productivity losses were caused by personnel issues. The ScrumMaster must pay attention to them to ensure the team is fully functional and productive.

Additionally in 2009 the following was added onto the March 2007 version (preceding):

The ScrumMaster is a facilitative team leader working closing with the Product Owner. He must:

• Ensure that the team is fully functional and productive;

• Enable close cooperation across all roles and functions;

• Remove barriers;

• Shield the team from external interferences; and

• Ensure that the process is followed, including issuing invitations to Daily Scrum, Sprint Review and Sprint Planning meetings.

In September 2010 it changed again:

The Scrum Master is responsible for ensuring that the Scrum Team adheres to Scrum values, practices,and rules. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Scrum Team by coaching and by leading it to be more productive and produce higher quality products. The Scrum Master helps the Scrum Team understand and use self-organization and cross-functionality. The Scrum Master also helps the Scrum Team do its best in an organizational environment that may not yet be optimized for complex product development. When the Scrum Master helps make these changes, this is called “removing impediments.” The Scrum Master’s role is one of a servant-leader for the Scrum Team.

Within scrum.org the definition is now:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. 

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Product Backlog management;
• Clearly communicating vision, goals, and Product Backlog items to the Development Team;
• Teaching the Scrum Team to create clear and concise Product Backlog items;
• Understanding long-term product planning in an empirical environment;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality;
• Teaching and leading the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and, 
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. 

The ScrumAlliance definition of the moment is again sparse with:

ScrumMaster: ensures that the team is functional and productive 

Scrum Master results and opinion

• Phew… where to start on this one. I consider the SM role to be an art. There is this careful balancing act that needs to be at play in order to enable the team to deliver and creating a self autonomous environment versus advising and teaching. The SM role to me is ultimately about improving the teams whole capability at delivering. How does an SM do this? Through behavioural adjustments – people skills are key so March 2007’s third bullet point is incredibly important, but now lost again.
• It should be the whole team not just the SM that removes roadblocks. What does an SM do if the roadblock is outside of their control though? Naturally they would help remove it but then this role is beginning to sound like a Project Manager to me… and Certified Scrum Master training says there is no such thing as Project Managers.
• Shouldn’t the team work out which interactions are helpful or not? Isn’t that the point of the retrospective? The SM is there to question the team and to plant the idea that the interaction may not be ideal but ultimately it is the team’s choice. That is what makes a self-empowered environment.
• Shouldn’t the SM be responsible for also ensuring the team is following first and foremost the Agile Manifesto and principles? I’ve seen plenty of teams that do the practices but then don’t treat each other with respect or have the courage to call out dysfunctions when they see them.
• What is ‘Scrum theory’ exactly? I suspect it means reading a whole pile of books and blogs because the detail doesn’t exist anywhere else.
• Facilitating sessions should be a temporary activity for the SM – ideally this would be rotated within the team as capability improves.
• Ideally the SM role should not take more than 10% of a person’s time (assuming a 8 person team). How much time they actually need to supply depends on three factors – team size, team Scrum capability and the stage of development (ie first sprint or 10th sprint). A team that doesn’t know Scrum will take longer to depend less on their SM. A three person team will transition generally quicker to a position not requiring a dedicated SM faster than one with 10 people. A team that is in their first sprint are still going through Forming, Norming, Storming, Performing and so will depend on their SM more to resolve some of the personality issues. Most Scrumists say it is a full time job, I normally advocate a half bell curve over the life of the project. As the dependencies decrease the SM can then actually start helping delivery of stories (ie can contribute on a different level). Nothing in the descriptions above deal with the timing nor in the contribution levels of the SM.
• The term ‘coaching’ is misleading. More often then not the SM is training and advising the team. True ‘coaching’, which I do believe is also needed, gets the team or individual to self reflect to reach answers to problems.
• The recent scrum.org definition now combines the SM and Agile Coach role. These are different roles and shouldn’t be combined the way it has been explained. In a small organisation then without a doubt it would be combined but it really is a different ‘hat’ that is being put on. An Agile Coach grows the capability of Scrum Masters, provides an overall adapted framework for the culture of the organisation and works on changing the mindsets of senior executive managers. In the terms of Shu-ha-ri: the team is in Shu, the Scrum Master is normally in ha and the Agile Coach is normally in ri. Choosing an implementation model is no small feat either but as always comes down to its own implemention of Agile – ie create an implementation backlog, prioritise, estimate and work to deliver results frequently.

The Team

In the 2007 pdf we have the Team defined as:

The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional. A Team is responsible for figuring out how to turn the Product Backlog into an increment of functionality within an iteration, and managing its own work to do so. The Team members are collectively responsible for the success of each iteration.

In both March 2007 and March 2009 the Team definition was:

The Team:

• Is cross-functional, with seven (plus/minus two) members;

• Selects the Sprint goal and specifies work results;

• Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal;

• Organizes itself and its work; and

• Demos work results to the Product Owner.

Within scrum.org the Team definition is now:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

 The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,
• Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

 Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog. 

The ScrumAlliance definition of the moment is:

Team: self-organizes to get the work done 

The team results and opinion