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.
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).
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:
- 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.
- 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.
- 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;
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.
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:
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
- Again scrum.org is coming up trumps in providing a really well thought out and detailed explanation including for the first time differentiating that the Development Team is subset of the Scrum Team.
- The recent version of text from scrum.org also explains a lot further what ratio of time size is preferred and justifies this well. The 7 (+/- 2) model was too restrictive. People may often miss the fact that this is more a guideline then a rule.
- I am frustrated with terms such as ‘Development Team’, ‘testing’ and ‘business analysis’ being used as eludes that Scrum can only be used for software development. Yes I understand that software development was it’s starting place but I would be more generic and say ‘Delivery team’ instead.
- The use of the term ‘cross-functional’ is also a pet hate. Only the recent scrum.org definition covers the depths of what it means in adequate detail but even then a major point is missing – why is a cross-functional team recommended? Ultimately it is because you want to achieve the sprint goals without having to depend on external factors. As soon as you have dependencies on those outside of the team to deliver user stories within the sprint then you are introducing risk. Many people miss the fact that a cross-functional team means a team that is first and foremost focussed on achieving the sprint goals (and when I say sprint goals I mean more the product backlog items that have been pulled into the sprint backlog). All too often I see team that have coded and ‘delivered’ the software for the stories inside of the sprint, but the testing is incomplete at the end of the iteration AND the developers have chosen to start new stories rather than help achieve the sprint goal – ie they would rather develop then help out testing to get the sprint achieved. The second intent behind the cross-functional team is that these developers should be focussing on the goal rather then their specialised domain. Where this gets interesting for me is when this is a regular occurence – ie the team are often performing duties outside of their standard specialisation. This is a smell for me. When this happens often – does this mean that the sprint goals are achieved? Yes. But does it do it at the expense of the team’s engagement? Yes. I would argue that if you put a great developer on testing duty for 75% of the project they will be highly unmotivated and it is for this reason that I actually believe the term should be “cross-skilled” rather than “cross-functional”. Cross-skilled infers that you can help out when needed, but that it shouldn’t be the norm where cross-functional is a little more open ended. My adapting too much to issues through a cross-functional team you are likely avoiding a particular flow constraint issue.
- Some of the wording in the earlier versions is suggestive that the team is the one that chooses priority – eg ‘selects the sprint goal and specifies the work results’. A clearer wording would be ‘determines how much can be achieved inside of the sprint and defines a way of working that will achieve this’.
- ‘Demos’ is probably not referring to a showcase and more a ‘hey, we think we have this story right – can you take a look?’
- You can see how a single word has a lot of potentially inferred meaning behind it – it is for this reason that short descriptions of roles and responsiblities are fraught with danger.
- I’m really getting a theme that the ScrumAlliance doesn’t want you to know anything more than a single sentence so that you have to go on training. A cynical person might think that it is a nice model to generate more revenue. For this I have to give scrum.org kudos of not shying away from giving something more meaningful to its readers.
- So where is the Project Manager in all of this? Scrum says that no such role should exist, nor needs to exist in a self-autonomous team but then that eludes to a governance model that is not consistent in a lot of organisations. Often, organisations have a gating process before work starts and whilst delivering Sprints they require Steering Committee oversight – who should be part of this within the team? The Scrum Master? In an ideal world the Steering Committee would turn up to the showcase and see the output to be comfortable. In an ideal world system environments would be in control of developers and not require negotiations with an external team. But most Scrum teams don’t live in this ideal world. There are inevitably external factors that mean the team isn’t in full control of its complete destiny and this is where a project manager can be effective – in ensuring that the team is effective. They are externally, outbound focussed handling pressures outside of the team.
- I have seen many projects that have software development components to deliver but at the same time have other components that have to be aligned – such as marketing/communications, training, business process re-development. Normally I treat them as all part of the one team as their stories will affect the success of the ‘product’. They have their own user stories which are prioritised against all the software development work, any dependencies are recognised. Because their work often only comprises < 5% of the end to end work I consider them part of the ‘extended team’. In this respect I have two ‘teams’ – one is the core team who delivers a majority of the stories. These are the people who are full time on the project. Anyone else is part of the extended team. This concept of two teams is not reflected in any Scrum content.
8 thoughts on “Scrum evolution over time: Part 2 – Roles”
It’s an interesting post but I think you’re trying to make sense out of something that doesn’t make a lot of sense to begin with.
I think that creating Scrum was not difficult, and you should be able to create your own process that is more suitable and a more worthy endeavor of your time.
Meantime feel free to take a look at my recent post on post agilism.
Bottom line — much of early scrum was winging it and inconsistent, and modern scrum is profit based.
It’s time to reboot agile and start afresh rather than try to patch up something that is such a poor/outdated/misdirected platform to start with.
Change is good right?
One thing though, that I think the scrum community might be interested is the dynamic of the SM versus the PO.
In a traditional business, the PM (usually a dev manager) is overall in charge of what when and how it will be delivered; the BA is not (although there is back and forth of course).
In Scrum, the PO is in charge, and the SM really cannot fight them…this leads to much technical debt. People blog about using subterfuge to pay off technical debt under the nose of the PO, it’s such a problem.
Are there different versions of this PO versus SM dynamic? Also if you were to parse out “what’s good” about scrum and backfill that into a traditional company, what would that look like? Plenty of people think it’s an all or nothing exercize but that needn’t be the case.
Also given the “group think” nature of development, and the voting etc, it seems odd to load the PO as basically an ubermanager with absolute control into 1 person. But my first comment may cover that, but still.
err traditional process rather feel free to edit that part of the comment since i cant