I’m on a journey to go through the complete Scrum Guide (2020 version) and turn it inside out. Hoping to find a satisfying answer to the question: “Does Scrum make sense?”
I started with “Purpose of Scrum” and “Empiricism”. I came to the conclusion that the premise of Scrum is sound. It is a framework that helps create a high-value product or service in a complex environment through empiricism (transparency, inspection, adaptation). Then I looked into the Scrum Values, which can indeed bring the pillars of empiricism to life.
In chapter 3, I discussed the Scrum Team. And while the premise still makes sense, I started to wonder: how often is it that a Scrum Team and its stakeholders work in an environment where all Scrum Values can be upheld, the team has no hierarchies and everyone understands the Scrum theory well enough to make effective use of the framework? I argued that the answer to this may be a reason why so many are struggling with Scrum.
Today I will continue my journey with the next chapter of the Scrum Guide which discusses the Developers.
The creators
In Scrum, Developers are the ones in the Scrum Team who are committed to creating the product. They are the creators. The Scrum Guide is very clear about what they see as a Developer: it is anyone in the team who contributes to creating a product Increment.
If your product is software related, you could have a team with architects, UX engineers, analysts, software developers, test automation experts, technical application specialists, database experts, and/or platform engineers. And certainly, this list is incomplete and simplistic. Because Developers also need to plan their work, present their product Increment, and align with stakeholders. These are thus also required skills for the group of Developers.
If your product has nothing to do with IT, you may have people with completely different skills on your team. The point is though, that the Developers together have all the skills to plan their work, create that useable Increment, and learn from feedback every Sprint.
I have to explain the above very regularly. In my experience, the concept of “Developer” continues to lead to confusion. This is why I would welcome a different term. I think the term “Creators” fits the bill better.
Owning the What, How, and When
The Developers are in charge of what they do to meet the Sprint Goal. They are also accountable for this. It includes:
Creating a plan for the Sprint;
Adapting the plan to maximize the chances of success.
The argument of the creators of Scrum is that the Developers should have the opportunity to creatively find the best way to achieve the Sprint Goal. Because the work is deemed complex.
In complex environments, you need to be able to respond to new information fast. It’s just like when you wish to travel from Paris to Berlin. Your navigation will choose the fastest route out of a selection of options. It will guide you to take the route via Frankfurt:
Now, suppose you are driving for an hour and your navigation system gets new information. The road between Saarbrucken and Frankfurt is blocked due to an accident. Your navigation system will simply tell you that another route, via Aachen, is faster and will start following that. Because the goal is to travel to Berlin. It is NOT to follow the route via Frankfurt!
The same is true for the Developers working to achieve a Sprint Goal. It is not about following the plan but about achieving the goal. If new insights tell you there’s a better way, you should be able to decide to follow that way instead.
When others than the people doing the work would have this final say, this would only lead to a lack of transparency, rigidity, and delays. Here are some scenarios that could happen in that case:
Developers might hesitate to share learnings as they may be considered a failure of the initial plan;
The Product Owner, Scrum Master, or other non-Developer may need to be convinced to change the plan which results in a loss of effort and time;
The person that has the authority to change the plan may not be available, resulting in a loss of time.
The non-Developer may not agree with the solution due to a lack of information.
Developers SHOULD own the what, how, and when to achieve the Sprint Goal. I agree this is the most sensible way to navigate in a complex environment. As long as they inspect their progress regularly. But that is a topic for a later article discussing the Daily Scrum.
Owning the sizing
Developers own the sizing of Product Backlog items. The Scrum Guide states that sizing may be part of the refinement, where details are added to an item to allow Developers to start working on it.
This makes sense as this is in line with the statement that Developers own the How of creating a product Increment.
Adhering to the Definition of Done
The Definition of Done is part of a later chapter of this series. It is a set of quality standards that are a commitment for the Increment. Without compliance with the Definition of Done, there’s no Increment.
It makes sense that Developers are accountable for adhering to the Definition of Done, as they are also accountable for creating the product Increment.
Being professionals
It may seem obvious that everyone should work as professionals. That is not the thing to highlight from the following phrase: “Developers are always accountable for […] Holding each other accountable as professionals” (SG2020). It’s the underlining that Developers hold each other accountable as they are self-managing. They should not rely on others to do this.
As this concept of self-managing teams isn’t an obvious thing in organizations, it makes sense to stipulate it.
Developers as part of the Scrum Team
I think it is good to highlight some aspects of the accountabilities of Developers within the Scrum Team.
Developers are part of the Scrum Team. They are not a team within a team. So, they are responsible for all product-related activities. This includes “stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required” (SG2020).
Everyone is responsible for the fact that whatever needs to happen happens. This means that a Developer may take the initiative to align with a user. Or that a Developer helps the Product Owner to maintain the Product Backlog.
As I stated in the previous chapter, this is good as you want everyone to consider and work on the larger picture of the product.
The accountability to deliver a valuable, useful Increment every Sprint is shared with Product Owner and Scrum Master. Every one of the Scrum Team must help to optimize the conditions to make this happen.
I also like that this is so clearly stated as it enforces the fact that the whole team has the same goal and focus.
Empowered Developers
I believe the main point the Scrum Guide makes is that the Developers need to be empowered. They need to control the WHAT, HOW, and WHEN to achieve the Sprint Goal.
I believe this empowerment of the Developers makes a lot of sense. They need to be able to adapt if new insights tell them an alternative approach will increase their chances to achieve the Sprint Goal.
But it goes further than this. Developers, Product Owner, and Scrum Master are part of a team that all share the same responsibilities for all product-related activities and the accountability to create valuable Increments every Sprint.
For me, the section about Developers and their role within the Scrum Team is very convincing.