3

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.

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

Karl Hill
  • 163
  • 4
Tea
  • 130
  • 4

3 Answers3

7

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.

Bogdan
  • 15,216
  • 27
  • 48
  • 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 '21 at 03: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. – Hans-Martin Mosner Nov 22 '21 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 '21 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 '21 at 03: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 '21 at 03:09
  • @Tea there may be part of your problem. If you have separate stories for your specialists, you're not working as a team, and it's understandable that developers see the team-oriented activities as an unnecessary burden. I would cut the stories such that each normally involves backend and at least one of the frontends, unless they are purely cosmetic changes or let one of the frontends catch up with a story that was previously only implemented for the other. In the latter case, web frontend devs may be able to provide valuable insights for mobile devs and vice versa. – Hans-Martin Mosner Nov 25 '21 at 07:51
  • I didn't separate stories, developers did. Backend often go ahead for a sub-story prepare any APIs that are necessary for frontend or mobile to go after. Then we have a small story for integration. What I tried to mention here is backend devs and frontend devs did not understand the work of each other. Let's say we had separated stories that belong to backend or frontend already when we do break tasks, only frontend talks about what they can do, should do, or how, the same thing happened with backend. I just want backend and frontend can share their knowledge. It seems hard @Hans – Tea Nov 25 '21 at 08:09
  • @Tea "you" in my comment was not directed at you personally, but as a generic term meaning the team that's having this problem. It's most likely not a problem of different knowledge levels in different development areas, but a communication problem. It would likely help to get an external expert into the organization who can analyze the situation and help find a way out of it. – Hans-Martin Mosner Nov 25 '21 at 08:34
  • @Hans-MartinMosner make sence. Thank you (y) – Tea Nov 25 '21 at 10:32
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.

Tiago Cardoso
  • 8,645
  • 6
  • 29
  • 72
-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.

Oladeji Oluwaseun
  • 21
  • 1