Self-managed teams - who has a say in decisions for the Scrum Team?
I love the idea of self-managing teams that is core to Scrum and Agile. However, I have a question about its practical implementation. According to the Scrum guide:
[The Scrum Team is] self-managing, meaning they internally decide who does what, when, and how.
No one else tells [the Developers] how to turn Product Backlog items into Increments of value.
My question is who should be considered as part of a team and who shouldn't? In some environments that line get blurred when some people work part-time or have other roles in the organisation and therefore are not 100% dedicated to the work in the sprint. For example, in the context of a software development Scrum Team, imagine there are certain technically knowledgeable individuals that head up communities of practice for some technology domains, are supposed to set technical direction for the organisation/department and line manage certain Scrum Team members. They attend every Scrum event, actively contribute to discussions and occasionally pick up tickets (maybe once every two sprints), do some code reviews, and sometimes assist developers with their tasks. But that's not reliable, they are not 100% dedicated to the team and the sprint, and they don't share updates at the Daily Scrums unless they have a ticket in progress. To me, this may be innocent as long as those individuals stay in the advisory and supportive role. However, I feel that it creates problems when they try to impose their views on how things should be done on the team as I see that as outside involvement in internal team matters. Can such people be excluded from decision-making on the basis that they are not fully-fledged team members? For example, should they be allowed to vote on the ticket size in Scrum poker during estimation? If they are highly unlikely to do the work themselves, why should their vote count? Likewise, in a situation where there is a disagreement on how to solve a technical problem between such partially involved individual and one developer (the rest of the team doesn't care or doesn't want to take sides) can the developer make a decision on the basis that he's part of a team and the other individual is not? Where is the line of being on the team and therefore having a say in decisions drawn? Can those partially involved individuals argue that they are just as equal team members as others since they do make some contribution to the development work but in their own way and to the extent of their ability (time-wise)?
There is a similar question for when the Product Owner is technically-minded and occasionally does some development work (say one small ticket every 2-3 sprints in one particular technology area). Should such a Product Owner be allowed to vote on ticket size in Scrum poker, have a say in resolving technical disagreements within the team (on how things should be done) and in how much works gets done in a sprint? The Scrum guide talks about accountabilities and not roles, therefore it assumes that one person may have both the accountabilities of a Product Owner and a Developer. This is a very confusing part of the Scrum guide to me as those accountabilities may conflict with each other. Could such a Product Owner argue that he does have a say on those questions as he occasionally does development work?
Thank you.
All of the questions you asked are the type that a self-organizing, self-managing team would decide for themselves. In the paragraph above your first quote is the opening statement of the Scrum Guide section that describes the Scrum Team.
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Notice that it does not provide a definition for the word "team". For that I go to Merriam-Webster.
a number of persons associated together in work or activity:
So putting those two together, the opening paragraph could read
"The fundamental unit of Scrum is a small number of persons associated together, a Scrum Team"
The next part is defining the three parts that that team consists of: one Scrum Master, one Product Owner, and Developers.
I am going to get a bit picky in this next part but I have found it to be useful in the past. The Guide states this in the opening section that describes the Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The key words for me in that statement are at the end..."each Sprint". Not "some Sprints", "current Sprints", or even "this Sprint". I believe in this context that the phrase "each Sprint" uses this definition of each from Merriam-Webster
being one of two or more distinct individuals having a similar relation and often constituting an aggregate
All of the people you state are sometimes contributors might not be considered Developers on the team. I would see them more as extra help that would abide by the decisions of the actual team members. They could have information that would help the team members in their self-managing, self-organizing activities but I would not invision them as team members.
Now, everything I said above is my opinion and only my opinion. Others may share it but because I wrote it, it is mine. In the end, my opinion is just information that can be used to form your own opinions and decisions. In this specific instance, you could use this as potential information that you pass along to your Scrum Team so that they can weigh it in their own decisions. Because this is a decision that the Scrum Team must make. And every Scrum Team at your organization might choose to make a different decision. That is the beauty of allowing teams to self-manage and self-organize.
My question is who should be considered as part of a team and who shouldn't?
Consider who is accountable for something and who isn't.
The Scrum guide talks about accountabilities and not roles, therefore it assumes that one person may have both the accountabilities of a Product Owner and a Developer. This is a very confusing part of the Scrum guide to me as those accountabilities may conflict with each other.
Think of it the other way round: they may not. Scrum is minimally prescriptive.
The Scrum guide talks about accountabilities and not roles, therefore it assumes that one person may have both the accountabilities of a Product Owner and a Developer. This is a very confusing part of the Scrum guide to me as those accountabilities may conflict with each other.
I'd say the Scrum Guide goes beyond assumption and states unequivocally that there will indeed be times when a Scrum Master or Product Owner will also be a developer. Note this quote on page 9 of the Scrum Guide:
If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. -The Scrum Guide
So the Scrum Guide certainly accounts for the fact that there are times when a Scrum Master or Product Owner will also be in the role of, or accepting that accountabilities of, a developer.