One Team Or Two Teams?

The Scrum Guide references 2 teams; the Scrum Team and the Development Team.

@Ed Rubuliak, Thanks for asking this question and I think its a really good one. You are right, there is only one Team, and that is the Scrum Team, however, the Development Team should be interpreted as a role because the members together are responsible for creating a Done Increment and that's the key word, together.

If you re-read the section in the Scrum Guide that details each of the 3 roles, it may give you clarity now.

I hope this helps.

Why, when the Scrum Guide insists that there are no sub-teams, we see there is a Development Sub-team that does not include the Scrum Master or the Product Owner. Already we are creating silos, are we not?

Perhaps we aren't creating silos so much as clarifying the accountabilities a cross-functional Scrum Team ought to demonstrate.

Thanks so much for these responses. And I totally agree. My suggestion would be that we call these, "roles" and not teams. To me, it is a fallback to the "old days". I am fighting this fall-back "tooth and nail" today. I personally call them roles in my training, coaching, and advising, and not teams, but I keep getting the response, "but that is what the Scrum Guide tells us, we have 2 teams." I fight it because I see it going right back to the divisiveness that we saw in the "old days." You see, I am a bit of an anomaly these days. I just celebrated my 52nd year in the I.T. industry 2 months ago. I began as a junior programmer straight out of college in 1968. I have basically seen it all. And "Agile" is the first success I have seen. I am passionate about Agile. I dropped out of Corporate Senior management 20 years ago and jumped on the Agile train, an ardent follower at that time of both Jeff and Ken (still am today). That is why I push against segmentation because whether we like it or not, culturally it pushes us back into silos, right where most organizations are comfortable today. Just my experience and observations. Thanks again so much for the responses. Keep up the great work!

I think the key point is that the Scrum Guide defines 3 ROLES and one of those roles will be filled by multiple people with specific skills.  The Scrum Guide never actually says that the Product Owner or Scrum Master roles have to be done by separate people.  However given the responsibilities of the role, it makes sense to have the roles fulfilled by separate individuals.  Same applies with the Development Team role vs the Scrum Master or Product Owner roles. 

Team may be a poor choice of words in this case but in reality you should be reading and understanding the responsibilities being stated and not get hung up in the words used to identify the roles.

I see Business Agility and Scrum in particular as a guide. It's not a commandment that I must follow. In fact, I have yet to find a company that has implemented Agile the way it should be. Everybody has their own flavor. So I wouldn't get too worried about the language, and would instead focus on intention.

The intention is to build quality products for happy customers, utilizing small get-er-done teams.

As a Scrum Master, I often remove myself from discussions involving just the Development Team.

Depending on the context, these can be technical conversations about the way the product is developed, and it can be wasteful (and potentially distracting) for me to be there.

I'm much less likely to step out of a discussion involving developers and the Product Owner, as this is more likely going to be something relevant to the entire Scrum Team.

I have made it clear to all members of the Scrum Team that I will involve myself when I believe it will help, and that I'd like them to involve me in any part of their work if they think it can be beneficial (or they're unsure).

One statement made, “Let’s not include the Scrum Master in this discussion because she is not a developer.” This troubles me because we are no longer a team.

I wonder what this reveals about the Scrum Values; particularly Respect.

This could be very respectful of the Scrum Master's time, and a deliberate choice not to involve her in a discussion which she will not benefit from, and be unable to contribute towards.

Conversely it may show a lack of respect for the Scrum Master's or Scrum Team's need to remain aligned as a team.

Perhaps the Development Team don't feel the Scrum Master respects their role, and so they are passively excluding her.

It could be that it has nothing to do with the Scrum Values, but actually just a misunderstanding about what is expected, and what is effective.

It may be wise to discuss this as a Scrum Team, and see what each team member feels would have been the best decision in that situation.