Slightly change the Scrum Roles definitions to avoid newcomer confusion
Newcomers have a hard time with two particular aspects of the definitions of the 3 roles: 1) the word "team" is used twice and that confuses people; 2) the word "developer" turns off a lot of non-coders.
I would suggest wording along these lines:
"A Scrum Team has a ScrumMaster, Product Owner and 3-9 other team members who have all the skills necessary to create a potentially releasable product increment every Sprint."
That way the word "team" is only used once. We get rid of the "developer" word that turns off non-coders. We make it clear the rest of the team needs ALL the skills necessary to create a releasable product increment (especially important so people that do testing realize they are part of the team). We have ScrumMaster, Product Owner and Team Member as the 3 roles and it is much easier to explain.
The topic of naming things in Scrum has 27 years of history.
When we look efforts that use Scrum, we find people bend some of the names to fit their culture. Sometimes just to “brand” it as their own.
Just remember empiricism, lean, inspect and adapt, self-organizing teams, and the values.
In the meantime, if you are bored or want to be noticed, don’t fiddle around with Scrum. Go for a run.
Dan Rawsthorne commented
I've always gone with "A Scrum Team has xxx members. The The team is self-organized and self-contained (able to get all its work to Done). Two of the Team Members have special accountabilities..."
David Sabine commented
I support this proposal. Upon reading the guide, it ought to be impossible that a reader reach the end and still ask these questions:
- "So, is the Product Owner *IN* the Scrum Team?"
- "At the end of the Sprint, the developers pass their work to the QA team, right?"
The guide currently uses the terms "Scrum Team" and "Scrum Development Team" in ways that cause misunderstanding (or, to be more polite, in ways which do not mitigate misunderstanding).
I like the sentence Bob has suggested: "A Scrum Team has a ScrumMaster, Product Owner and 3-9 other team members who have all the skills necessary to create a potentially releasable product increment every Sprint."
Joshua Partogi commented
"developer" is not only referring to coders. "developer" is someone who develops, in this case, in this case the development team is developing a product. a product is not necessarily a software. so the developer is not necessarily coders.
Alan Larimer commented
I understand the intents and I understand Specifying to which team one is referring can be a challenge. Mr. Hartman, find all occurrences of "Development Team" in The Scrum Guide and think about how this change would affect it. (*waits quietly*) That creates quite a mess in my opinion. Of course that in and of itself is not enough hopefully provokes thinking in different terms (pun intended).
I do like the notion of changing the "Development" term as you and others have noted. Overall, the idea that the others are a team is too important to drop the term.
Delivery/Production/____ Team is the question in my mind.
Pierre Neis commented
Disagree. 3 roles are enough and if your team is maturing, scrum master becomes obsolete. Less is more. If the focus is given to new roles you will reduce the expected "complex" or agile behavior in that system called scrum by emphasizing structure. Scrum is organization over structure. No?
Pierre, I respectfully disagree. I'm not changing anything by saying the PO and SM are part of the Scrum Team. That is in place today. Also, the Scrum Guide is very clear that the Scrum Team self-organizes, so again, no difference. If the PO being "on the team" is an issue, then it is already an issue today. In my opinion the confusion around wording is important to resolve. If it causes other unforeseen issues then let's be agile and adapt. Right now we have phrasing that is confusing to people and actually turning some people off because they don't believe they fit. How many organizations think it is ok to have QA offshore in a following sprint because the "developers" are on the "development team" and that's all Scrum says to do? Clearly this is wrong thinking, but they don't understand and we aren't helping them understand with the current description. I've now helped over 10,000 people learn Scrum and this is a constant issue in their understanding. I know other people have helped more than I have, and I respect that, but this change seems like it could help make understanding easier which is why I suggested it.
Good Article on Slightly changing the Scrum Roles definitions to avoid newcomer confusion...it's really informative article.
Pierre Mengal commented
I agree that the term Developers is not appropriate in many modern contexts where teams are composed by an increasing variety in profiles. I would replace it by "Professionnals" or a more generic term as the ones suggested by Rob Myers.
I also agree with Michael James (MJ) comment about the team. The "Scrum" Team seems less appropriate than the "Development" Team which exist as itself to promote self-organisation and necessary empowerment. I see three problems with the "Scrum" team approach. First, if the PO becomes a member of the team, there is no clear boundaries anymore and some of them may be tempted to interfere with the definition of the development practices which are a responsability of the "Developers" as a team. Secondly, a PO (and a SM) may be a part of multiple different teams working on different products. Thirdly, as a extension to the previous point, a PO in Scrum is clearly more linked to a "Product" than a "Team". In the context of scaling Scrum, a single PO feeding multiples teams is commong and his extended membership will add more confusion to the whole organization.
Bas, I'm probably going to regret asking this, but why do you say:
"To me, looking at the "development team" as one rather than separate team members is essential to Scrum."
They are still a team, just in the larger context that contains the PO and SM and that entire group is responsible for creating the potentially releasable product increment. I don't believe it is only the Development Team involved in creating the potentially releasable increment, or the PO could just go away and never answer questions and the SM could not remove impediments and they would be ok doing so. I'm clearly missing something for why you believe the separateness is important.
MJ, I see very different results from you. I describe it to people exactly the way I wrote it. I then point out that the Scrum Team is self-organizing and has no hierarchical structure. Each role has it's own rights, responsibilities and characteristics, but the entire Scrum Team is responsible for doing their part to help create a potentially releasable increment every sprint. The Scrum Guide already says the Scrum Team is self-organizing (see Scrum Team section: Scrum Teams are self-organizing and cross-functional) so there is no change needed there. I really don't see why getting rid of the inner team makes the outer team not able to self-organize since it is already supposed to be doing so. Our experiences clearly differ.
Michael James (MJ) commented
This week in a discussion group we've seen how dissolving the original team (now the inner one) naturally leads to something I'll call D-Scrum: A CST has advocated that the PO is a "team captain" between the team and the real business decision maker. This idea (also found in the traditional organizations such as the Army) would more accurately be called "manager led team," not self managing team. It also leads to yet *another* role called CPO or "business owner."
Team within a team was a compromise from the get go. If we can't live with it, we should discard the outer wrapper "team," or use some word other than "team" for it. Saying "everyone's on the team" is a simple and seductive statement, but the effect in practice has been the erosion of the real self organizing team.
Rob Myers commented
"Developer" doesn't just alienate non-coders, it alienates coders, as well. These are people who frequently have years of training or experience in computer programming, and have earned the title of Software Developer. Also, I teach CSD, the D stands for "Developer." A requirement of CSD is programming using Scrum Developer practices. I.e., practices well-suited to software development on a Scrum team. If we want to decouple Scrum from software (which is fine), we need to make it clear when we're talking about using Scrum to deliver software. When speaking generally, we could use "teammate," "contributor," or even "craftsperson" without pointing towards any particular industry.
MJ I wasn't trying to solve that problem. It exists today as well, so no change there. I was going to make Scrum roles easier to understand. Since the SM is part of the Scrum Team today, that doesn't change so I don't see their ability to facilitate compromised by this change. Is there something better such as your suggestion? Maybe, but my concern would be that with two people not part of the team then motivations change between team and non-team members. I prefer everyone on the team and the team is responsible for everything through various roles and responsibilities. I don't like a team within a team and I don't like the phrase "developer" (even though I was one for a long time) because too many people hear the word and think it isn't them even when it clearly should be them.
Michael James (MJ) commented
The team within a team was declared in the 2007 book _The Enterprise And Scrum_. A simpler solution would be to revert to the pre-2007 definitions: There's a team, a Product Owner, and a Scrum Master.
A team isn't really self organizing if particular members have special roles or authority. (Imagine saying "Pat's in charge. Now self organize!") The Product Owner explicitly has authority, so isn't really a member of a self organizing team.
The Scrum Master's service to the team is also compromised by being within the system they're facilitating. Per https://read.amazon.com/kp/kshare?asin=B000PY4V9M&id=jqsXtBzmRsGXfA35fS5_GQ&reshareId=3WZ3MHQFDKCFAVTC1J05 "To ensure that the facilitator is trusted by all group members and that the group's autonomy is maintained, the facilitator should be acceptable to all members of the group; this person needs to be substantively neutral-that is, display no preference for any of the solutions the group considers-and not have substantive decision-making authority. In practice, the facilitator can meet these three criteria only if he or she is not a group member."
Anonymous, Team is kept. The Scrum Team. Team on its own is not core to Scrum at all. There is Scrum Team and Development Team, so which are you referring to? You sort of just proved my point about why this needs to be changed.
Keep Team. It is core to scrum.
Murali, I'm not sure what you mean with your question. If a role isn't helpful toward creating the releasable product increment then why would it be on the team in the first place? I don't see this proposal changing anything except helping non-coders recognize they absolutely SHOULD be in the team if they are part of creating a releasable increment.
Murali Varadarajan commented
Bob of all the roles that can be removed without losing ability to create which do you think will be first ?
An honest answer please ... ?
Jef Cumps commented
Ron Jeffries commented
I think there's real merit to this idea.