Scrum Roles — Team Role

Note: This is one in a continuing series of posts re Scrum Intro.  The preceding post is here.

The next role is commonly called the team role (I am not happy with the name).

There is only one team worth talking about: the whole Scrum Team, which includes all three roles. The team wins or loses together because of all of the efforts of all of the people, including those who support the team (that is, people outside the team also).

So, I call the people in the team role the “Doers” or the Implementers.

What can we explain about them?

Well, if the total team is seven people, that leaves five to be the Implementers. The five Implementers should have all the skill sets to build and verify and validate the product. In software terms, you must have at least coders and testers. This is important and often misunderstood. A Scrum Team doing software must include testers. For a story to be completed and working by the end of the Sprint, it must be professionally tested (and the bugs fixed) by professional testers during the Sprint.

Again, the Implementers should have all the building verifying and validating skill sets for whatever product the team is working on.

Does this ever happen?

In my opinion — never. The team always has most of the skill sets, but not all. So, the Implementers must rely on people outside the team to provide, one way or another, some of the skill sets.

How much are the Implementers lacking?

We should hope they have 98 percent or 95 percent. This happens. Or maybe 90 percent, but not always. We will not bother to define 90 percent coverage, but to me at about that level, the team is seriously compromised in terms of doing quality work in a tight timeline. Almost always, that is what is wanted. So, the Implementers must be honest about where they are lacking skill sets. Again, getting humans to be this honest is challenging.

The team must be team players, as we say. The team must help each other, and the strongest person must teach the others the skill set that he or she is strongest in. (Well, use common sense, which is very uncommon.) But the key thing is that it is about the team success and not about what an individual did. (We are not against recognition for individuals, but we want the team to be stronger. This is a team sport.)

Taiichi Ohno (famous for Lean) is famous for using the rowing metaphor. They must all row together in the same direction to be successful. I am not sure the rowing metaphor, as with any metaphor, is completely apt in every circumstance, but we think in America at least it needs to be repeated and discussed more. (Cf “Toyota Production Systems” by Taiichi Ohno.)

If a team has a dominant individual who will not let the team work together, then ultimately the SM must get that person removed from the team. At least very commonly that turns out to be the correct solution. Often that person is clearly the most talented person on the team on paper, and most think so, and yet, paradoxically to some, once that person is removed, the team’s velocity goes up.

Should the team include a BA, an architect, a DBA, an X or a Y?

It depends. It seems to work sometimes. It seems not to be necessary all the time. Overall, it is really helps to have a great team. In this statement, we mean not only the team role people but also the PO and SM and how they all work together.

If you already understand Scrum as a team sport and you understand team sports, my statement is completely obvious and almost silly.  It is remarkable how many companies (apparently) do not understand these basics about teams.

Note: The next post in this series is here.

 

« « Scrum Roles — The ScrumMaster || The Whole Scrum Team » »