Who are developers in Scrum team?



  • 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 https://www.tutorialscampus.com/agile/scrum-team-structure.htm .

    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?



  • The Scrum Guide used to mention a development team, but now it just mentions developers. Here is an https://www.infoq.com/articles/changes-2020-Scrum-guide/ 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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2