3

When I worked in my previous company (Axon Active), they do apply scrum by separating each team with the same member role. Let's say we have teams with all members who are 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 said why the scrum team now can be worked with many people with different roles? Let take a look the picture

enter image description here

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 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. 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. 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

  • Whether I missunderstand concept of Developers in Scrum Guide?

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

1
6

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.

9
  • Thank for your answering my question. I still confused if we have many roles in a team. How we can make an effective Sprint planning ?
    – Tea
    Nov 22 at 3:21
  • 2
    @Tea, have you tried planning poker? The idea is that all team members (even those who are not familiar with the area of a backlog item) present an estimate. If there's a clear outcome, for example when all backend devs estimate a story at 2 points while the frontend dev just guesses 3, a short discussion may lead to a consensus. If estimates diverge wildly, there might be a misunderstanding about the complexity, and it might be helpful to clean up that misunderstanding. This will also help those who are not experts in the given area to get a better understanding and better future estimates. Nov 22 at 15:43
  • 1
    @Tea: collaboration as a team is, again, the way you can make a successful Sprint planning even if you have different roles in the team. See for example this question How does Planning Poker work in a cross-functional team?, that also touches on the previous comment Hans-Martin Mosner posted.
    – Bogdan
    Nov 22 at 17:44
  • We did @Hans-MartinMosner But it's hard for backend developers when frontends cannot truly understand what is real technical problems in backend. We have separated stories for backend , front end and mobile devs
    – Tea
    Nov 25 at 3:00
  • @Bogdan Thank you, I see your point. In real situation, team have to good at collaborating skill, this point was missing in my team.
    – Tea
    Nov 25 at 3:09
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.

1
  • I see your point. I think we need to adapt the process with new setup of team
    – Tea
    Nov 25 at 3:41
-1

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.

1
  • Sorry, but your answer is too generic.
    – Tea
    Nov 22 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.