Development team in scrum

development team

The definition of the development team is not so easy in scrum; the development team are not composed just by developers.

The development team

The simplest interpretation before even looking at the scrum guide would be: we have 3 different roles in the scrum team and the 3 roles include all the skills to set up a product with complete autonomy.

In this scrum team, we have:

So, all those who are not product owners or scrum master who participate fully or partially in the product are in the development team.

Now back on the scrum guide, to reinforce our analysis because the last statement seems too simplistic:

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. A “Done” increment is required at the Sprint Review. 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 the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
  • Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

The scope of this team

Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment => Although we often talk about technical members when we talk about the development team, in this part, the scrum guide is much more general about the scope. Assuming no specific skills, we can assume that it is talking about all skills without exception.

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, => This sentence is very interesting because it quotes other areas than pure technical aspects like functional analysis.

So we can consider that the domains mentioned are part of the areas of expertise of the development team:

  • testing
  • architecture
  • operations
  • business analysis

However, if we use other roles than the product owner to work on the functional part like the Business Analyst, the UX, the tester (on the functional specification part of the tests), how can we classify these people?

If we refer to this part of the scrum guide, they are part of the development team.

Curious? No lah.

The concern is that the term development is currently associated with programming; 20 years ago, we were not talking about developers, but about programmers. I don’t know exactly the reasons for this change but it is an observation that I make since my beginning of career.

Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment; => this sentence could also confirm the generality given to this development team.

And our experts in partial presence?

On this point, there will be differences of interpretation. And it’s interesting to analyze them.

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.

Can we consider that the members of the development team are present at each sprint? If we put an accented reading on « at the end of each sprint », we could say that. So the experts present partially (not every sprint) can be considered like “non member” of this team.

Example:

  • one lawyer who comes to help on a functional specification only few times.
  • one person coming to test a feature to validate 1 user-story, once in a while. In hospitals, in imaging, it’s sometimes mandatory to call a specialist to make a real test (only able to use the machine).

But others will say, we can be « member » of this team over a short period of time; the « at the end of each sprint » section is only present to talk about the sprint end increment. This is another interpretation quite acceptable.

But if we go back to the first paragraph we saw:

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team

This sentence can ultimately be read in many different ways. « all competencies needed to accomplish the work » may mean achievement from the clearly specified request or say that the team is doing the work that has been asked of them while specifying it.

So those who consider our lawyer and our radiologist (temporary tester) as a “member” of the development team and those who consider that they are “non-members” of the development team, potentially have right.

Honestly, it is not very serious because the main thing is to make everyone work in the best possible harmonies.

Then my users?

The user can be part of this development team. We will see different cases.

1 / If my user comes for example in the development team regularly to write the functional tests with the developers: he is a member of the team.

2 / If my user only comes to review to see the finalized increments: he is not a member of the team.

3 / If my user comes for example in the development team from time to time to write the functional tests with the developers: he is a member or not a member of the team (according to the interpretations).

4 / If my user comes on the development team to help the Business Analyst to complete user-story management rules: he is a member of the team.

As we can see, it is not so easy to define who is a member or not a member of the development team. Some might even question these results with the sentence below where « accomplish » can be interpreted differently depending on the people:

If my user comes for example in the development team from time to time to write the functional tests with the developers: he is a member or not a member of the team (according to the interpretations).

The little things that will scratch

Although some will say, don’t do scrum by the book, here are some interesting information.

No Business Analyst and UX

So, all those who are not product owner or scrum master are part of the development team. But a phrase from the scrum guide can embarrass some people:

“Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;” => If we talk about a 100% respected scrum, no one can have the BA or UX title. Each member of the development team has the title of “member of the development team”. But we can have members with specific skills to help product development as shown in the sentence below.

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

This sentence may appeal to the fact that the work of the Business Analyst and the UX are the responsibility of the whole team. The entire development team can thus criticize (positively) the functional work done by these people. In the opposite direction, members with non-technical skills may also criticize the work of developers for example.

Be the first to comment

Leave a Reply

Your email address will not be published.


*