The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.

Today we are going to talk about the one of these terms in the Scrum Glossary: Development Team. The glossary has the following description:

Development Team: the role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint.

The Development Team is one of the mandatory roles for using the Scrum framework. No surprise here where it says something in the description about accountability of this role. I’ve seen a lot of misinterpretations in practice about this accountability though, so let’s break down the description and analyse what’s really being said here.

the role within a Scrum Team

Notice how it says role within a Scrum Team. Note: The Development Team role is part of a bigger team called the Scrum Team. When we talk about the Scrum Team, we are talking about the Development Team, the Product Owner and the Scrum Master role, together as an entity. However because roles in Scrum have a clear accountability to them, the Development Team role differs from the Product Owner and Scrum Master role based on the difference between accountability the Scrum Guide describes for them.

accountable for managing, organizing and doing all development work

Here’s where the description goes into detail about the accountability of the Development Team role. Note how it doesn’t say anything about Development Team members. This is because the accountability of the Development Team is at the level of the accumulation of people fulfilling the role in a single Development Team and not its individual members. This is a common misinterpretation when organisations try to evaluate Development Team members. As accountability is at a higher level than the individual this introduces antipatterns where people will be trying to sub optimize to increase their individual performance.

Managing, organizing and doing all development work means more than just coding the software. It means any planning needed to do so, tracking the plan to do so and adjusting the plan to do so needs to be done by the Development Team. It also means deciding who does what needs to be done by the Development Team. It also means solving issues related to the development work needs to be done by the Development Team. I commonly see a lot of these activities being done by Scrum Masters or Product Owners while it is not part of the described accountability for these roles. The idea of self organisation is rooted in this part of the description. By taking full ownership of “how” the work is being done by not having someone else make these decisions, the Development Team will be incentivised to think of the best way to do their work.

required to create a releasable Increment of product every Sprint.

All this effort in managing, organizing and doing the development work is for this reason only. The success of a Development Team cannot be measured if they are not capable of creating a releasable Increment every single Sprint. Common misconception is that this means the Increment will actually have to be released every Sprint as well. There’s a difference between the terms releasable and released. As Scrum is an empirical approach to product development the Scrum Team needs to be able to get feedback on a product in a state of usability in which the customer would also be using it in a released context. Or at least as close as possible to this state, to ensure feedback given is not invalidated because “It works different in production”. To do so we need a releasable Increment, and not necessarily a released Increment.

Combining the last two parts of the description paints an image of a focused Development Team doing everything they can to create a releasable Increment every Sprint. This picture is completely correct, but also needs a slightly more nuanced explanation. It doesn’t say anything about scope of the Increment in the description. Because of the complexity of product development being fluctuating at best and volatile at worst the Development Team needs to take this into account when managing their work. They need to do this as it’s not only important as part of the product development process, but also as part of working at a sustainable pace. In the article about the Sprint Goal we will dive a bit deeper into this.

Conclusion
The accountability of the role of Development Team is often misinterpreted as being one on the individual level, overlapping with Product Owner or Scrum Master roles or as needing to be always releasing to production. I hope this articles let you explore a few of the pitfalls when looking at Development Teams and helps understand the term as described in the Scrum Glossary a bit better.

Did this help you? What’s your experience with misinterpretation of the role? How’s your current Development Team doing? Let me know in the comments and we’ll discuss.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*