Who are developers in Scrum team?

Question

When I worked in my previous company (Axon Active), they apply Scrum by separating each team with the same member role. Let's say we have teams with all software developers, software testers or business people, etc. I was admitting that is the right way to approach Scrum.

Today, when my colleague shows me a picture on the internet, it makes me so embarrassed to explain. He asked why the scrum team can now work with many people with different roles? So let's look at the picture.

I tried to take a look in Scrum Guide 2020, but it's no useful information:

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

I can see so many obstacles while he tried to apply the new approach that treats all people as a team. His team now has three backend developers, two front-end developers, two testers, 2 BAs, 1 Mobile Developer, and the Sprint Planning is so ineffe

Blockquote

ctive in my point of view. In my old teams, all members contributed to sprint Planning. Everybody knows how to do a story with tasks broken by the whole team. Compared with his team, backend developers don't understand and can not give any suggestions for front-end developers, same with other roles—fewer contributions, less effective.

My questions are:

1. Whether I misunderstand the concept of Developers in the Scrum guide?

2. Could anyone share the approach of your team or your company to deal with the problem above?

Answer 1

The Scrum Guide used to mention a development team, but now it just mentions developers. Here is an explanation of the reasong behind that:

The 2020 edition no longer mentions the development team, but talks about one team - the Scrum team. What does this change intend to deliver, and what do you hope that will happen in teams and organizations using Scrum?

Schwaber: The goal was to eliminate the concept of a separate team, the Development Team, and instead have one team focused on delivering value. The separate Development Team could create ‘us and them’ behavior between the product owner, the Scrum master and developers. By removing the Development Team, we have one Scrum Team focused on the same objective. The three accountabilities describe how they all work together to deliver on that objective.

This 'us vs them' can go even deeper than just between the PO and a development team. The developers can have this attitude among themselves also. I'm a backend developer, I'm a frontend developer, I'm a designer, I'm a tester, etc. I've done my job, now it's your job, or, that's not my job.

It would be ideal if people in a Scrum team had all the same skills and could all do each other's work, and titles wouldn't matter, but in the real world people have specific roles and skills based on the career they have chosen for themselves. So you do get backend developers, and front-end developers, and testers, and designers, etc. That's still fine (and in some situations preferred) as long as they collaborate as a team.

Placing people together doesn't make them a team. The way they work together does. Then roles no longer matter and all can call themselves 'developers in a Scrum team', because that's what they do, they put together their different skills to develop the product.

Answer 2

His team now has 3 backend developers, 2 front end developers, 2 testers, 2 BAs, 1 Mobile Developer, and the Sprint Planning now is so ineffective in my point of view.

This team structure looks pretty solid for a team ramping up on Scrum. If the team is planning and prioritizing stories that deliver value at the end of the Sprint, the team has all the skills needed (granted, some skills introduced by specific roles are expected to be absorbed by the developers themselves in the long run).

In my old teams, all members contributed to Sprint Planning, everybody know how to do a story with tasks that were broken by the whole team.

What are the specific reasons members aren't contributing to the stories? One of the recurrent anti-patterns I observed over the years is teams breaking down stories by technology, so the team ends up with a story like "as a user I want to be able to enter a password in the login screen" and another Story "as an application I want to be validate if my password adheres to the minimum standards" when the actual story is "As a user I want to be able to login into the system". This may be broken down into different stories but the functionality will still cover both front and backend (and QA, and BA, for the matter). The story is prioritised for the Sprint, and as part of this unique Story, the whole team will work together to deliver it.

Compared with his team, backend developers don't understand and can not give any suggestions for front-end developers, same with other roles. Fewer contributions, less effective.

Although it's a plus if they can (and they should strive for having T-shaped skills) it's not mandatory. If you're prioritising "pieces of work" based on each one's skillsets, you might end up with a mini waterfall. For instance, if your sprint looks like "BA does the analysis > Front & BackEnd develops > mobile ports > QA tests" you're waterfalling your sprint. The BA helps at every moment during development process by clarifying the rules to be followed, the QA keeps closely observing how development is going and creating test cases for it, raising corner cases and potential usability problems, whereas the development of the feature is done in parallel, at the same time, by front, back and mobile developers. It's not trivial and does require much more maturity from the team than working in a waterfall-ish model. But it definitely pays off. And by doing so, each one learns a bit from their peer's skills, to the point that most seasoned agile teams no longer have nor need a BA neither a QA. They're just developers with proper business and quality assurance knowledge.

Answer 3

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work.