The Development Team, more than just a team of “developers”

If you’ve worked with Scrum teams, you have probably wondered who is part of the Development Team. For example, are all developers that write code in the Development Team? What happens to those who do not write code? Are they also "developers"?

In fact, I have often been asked this question by members of Scrum teams with whom I have worked and it has even been the subject of debate in the agile community of Paradigma. Let's shed light on the question!

The heart of a Scrum team is the Development Team. Some interpret this name as the team composed of members who "write code". However, the best Development Teams do many more things besides writing code, even though this task is essential to achieve delivery in a Product Increase.

For example, UX specialists help the team understand customers while providing solutions and support to other developers who write code.

Another example would be the QAs, guardians of the quality of the Product that ensure, among other things, that the written code has undergone the necessary tests. This way we could continue with the Analysts, with the specialists in Systems and Operations, etc.

Therefore, it is obvious that they contribute to the creation of an increment by writing code, so the term "developer", as Scrum understands it, goes beyond pure programming.

In fact, it is worth citing Scrum.org's definition of the term "developer":

"Developer: any member of a Development Team, regardless of technical, functional or other specialty".

That is, it does not matter if the contribution is technical, functional or in another specialty in order to be a member of the Development Team.

However, it is not enough for "developers" to be specialists in a given area of ​​knowledge. One of the keys to making a truly agile team work is that it is composed of multifunctional members, rather than hyper-specialized ones.

It is not enough that the composition of the team is cross-functional, in an ideal team, all the "developers" must be able to contribute in multiple dimensions.

The term cross-functional is closely related to another anglosaxon concept in the world of recruitment: T-shaped skills. This term is used as a metaphor to describe the skills of a person to contribute to their work.

The vertical pole of the T represents his dominant ability, his specialty, the area of ​​knowledge where that person is strongest. While the horizontal stick of the T represents other minor, but present skills with which that person can contribute to their team.

Therefore, it is important that the members of a Development Team reflect on their abilities and become aware that, in addition to being specialists in a subject, if they work in a Scrum team and aspire to be Awesome Development Team Members, they must also work actively on the horizontal stick of their T, on the abilities that will make them cross-functional members.

Don’t lose sight of the fact that, in a Sprint, there is a job to finish, a Sprint Goal that must be reached, and being able to count on multiplayer players is always an advantage.

Going one step further, it is not just about Scrum; If we want to be Great Teamwork Professionals, it is not enough to know a lot about one thing, we have to expand our knowledge in other areas to communicate better with our colleagues, understand their problems and be able to help them.

Surely you've seen the movie The Three Musketeers, do you remember their motto? "All for one and one for all". Well, something like that.

Members of a Development Team are expected to do whatever is necessary, whatever the task, to deliver an Increment at the end of the Sprint. The T-shaped skills concept not only applies to skills, but defines a mindset, a way of acting as a team, sharing purpose and responsibility. Teams with this mentality, are not only more resilient and respond better to change, but are more collaborative and creative.

It is true that it is very difficult for all the members of a Development Team to know all areas of knowledge involved in the development of a Product, it is paramount to impossible.

But, on n the other hand, what happens when a single member of the team monopolizes an area of ​​knowledge? For example, what happens when only one person on the team knows how to deploy or solve an infrastructure problem? Or, what happens when only the QA, or certain developers, know how to write tests and / or perform tests? Well, in addition to a bottleneck, is a great risk to the Product.

This mentality is called I-shaped skills and is very common in newly created Scrum teams. It reflects a way of thinking and acting: "This is what I do, who I am and I am very good at this particular skill".

Conclusions

In the Development Team all team members are "developers", whether or not they write code. In addition to writing code, great Development Teams carry out many other activities (involving other areas of knowledge) of great value for the Product.

In fact, Scrum does not recognize titles or sub-teams within the Development Team. What Scrum does admit is that team members can have specialization domains, although the responsibility to the outside lies with the entire team.

The most outstanding Development Teams have a T-shaped mindset. They are composed of multifunctional members capable of providing value in multiple dimensions. They dominate a specialty but they also contribute to the team's work in other areas, they are great players with team vision!