Three Common Developer Blunders in 5:05 Minutes—Making Your Scrum Work #14
TL; DR: Common Developer Blunders — When Your Scrum Team Lacks Alignment
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. While it is common to first look outside our team for impediments, such as dysfunctional processes or other systemic issues, I would advise starting with the Scrum team’s way of collaboration: Are we aligned on the why, what, and how? Otherwise, the three following Developer blunders may diminish the team effectiveness.
📺 Join me and explore the consequences of these Scrum Developer blunders and what you can do about them in a little more than five minutes.
Update: I am running a poll on LinkedIn—join the voting: “What common ways have you observed how Developers diminish the value creation of their own work?”
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
The Accountability of the Developers According to the Scrum Guide
The Developers bear a mission-critical responsibility: they create the Product Increments designed to provide continuously more value to our customers:
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. However, the Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals.
Source: Scrum Guide 2020.
Moreover, as the Scrum Team is self-managing, the Developers decide how they plan to do this. The Scrum Guide lists this critical element of the Developers’ contribution to a Scrum Team’s effectiveness in another section, the Sprint Planning:
No one else tells them how to turn Product Backlog items into Increments of value.
Source: Scrum Guide 2020.
Developer Blunders: Autonomy without Accountability Diminishes Value Creation
“With great power comes great responsibility” is a suitable introduction to the root cause of the following three Developer blunders. In my experience, it is not uncommon that Developers focus their work on a subsection of the value creation process, the coding itself. However, to maximize the value created from the work of the Scrum team, the Developers need to get comfortable with two principles:
- They need to involve themselves in the product discovery process as early as possible, for example, by actively supporting customers at the help desk or by running user interviews. Writing code is only the last step of the process, once you have figured out what is worth building.
- Another area prone to Developer blunders is establishing a collective responsibility for the product quality and keeping technical debt at bay. Attitudes like “works on my machine” or “we can ship it, just write a bug ticket for the remaining two issues” will not be sustainable.
Cannot see the form?
Please click here
Let us delve into three Developer blunders, all of which a Scrum team can address themselves in an indeed “15 % Solution” spirit:
The Developers Focus on Coding
The Developers focus on delivering “code” and only code. They have no interest in talking to customers or take over customer support duties to understand their problems first-hand.
From my perspective, the Developers are missing an essential part of the value creation process of a Scrum team. The Manifesto for Agile Software Development describes it as follows: “Simplicity–the art of maximizing the amount of work not done–is essential.”
Hence, it becomes necessary that all Scrum team members talk directly with customers to understand their challenges better and avoid the misallocation of the Scrum team’s development time. (My rule of thumb: Coding is no more than 50 % of the whole effort of creating value for our customers. The best way to increase the productivity of a Scrum team is to avoid building unnecessary stuff. Now, guess how you can best address this issue? Right: Developers talk to customers.)
Works on My Machine, or: We Will Fix it in Post
The trust of the Scrum team in its own creation is so low that they run “hardening Sprints” from time to time to improve the overall quality of the product.
If there is one thing that comes to mind regarding Scrum, it is the relentless focus on quality, expressed in the Definition of Done and delivered with every Increment. As a Scrum team, our quality goals never decrease; there is no cutting corner whatsoever, such as “it works on my machine.” Whatever we create, we adhere to our Definition of Done; there is no need to fix issues later in production as we do not ship undone work.
Therefore, a hardening Sprint is commonly a sign of a low grade of adoption of agile principles by the Scrum team or the organization. There are plenty of reasons for that; for example, the Scrum team is not yet cross-functional or at an early stage of its Scrum adoption. Alternatively, the “QA department” may still be a functional, non-agile silo. The organization’s incentive structures probably favor the output of the individual over the outcome of the Scrum team. (Which often results in the creation of a feature factory, accumulating technical debt.)
Gold-Plating, or: Why Over-Delivering Is an Indicator for the Developers’ Lack of Professionalism
This Scrum anti-pattern is easy to spot: The Developers increase the Sprint’s scope by adding unnecessary effort to work items of Sprint Backlog, also referred to as scope-stretching or gold-plating beyond Done. Typically, this is done without prior consulting of the Product Owner.
This ignorance of previously made agreements during the refinement process may result in a questionable allocation of resources by neglecting basic business principles like considering opportunity costs.
What can you do about when faced with gold-plating? Try to address the following issues in the next Sprint Retrospective:
- Are Developers and the Product Owner talking often enough with each other, is the Product Backlog refinement process up to the job?
- Are the Developers aware that it is their responsibility to make sound investment decisions when creating Product Increments? Good enough, as in “meets the Definition of Done and the intended purpose,” is a viable approach. It does not always need to be the most elegant, best possible quality solution as long as the Increment delivers the intended value.
Probably, you also want to analyze whether decisions made in the past, for example, the design of extended software architecture, are now driving decisions. So, for example, developers might be doubling down to underline that the previous decision was correct.
Finally, as we are all humans, brace for the occasional over-excitement on the Developers’ side. Sometimes, a third and brand-new JavaScript framework is simply needed in your application. #sigh
Common Developer Blunders — Conclusion
“With great power comes great responsibility” is an excellent mantra for Scrum Developers. Professionalism here means to accept accountability for making many investment decisions, which requires looking beyond mere coding from day one. The good news is that Scrum teams can deal with many challenges on that path themselves—it is a question of collaboration and alignment among team members.
Have you noticed home-grown Developer blunders or organizational dysfunctions that lead to those? Please share them with us in the comments.
✋ Do Not Miss Out: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Developer Blunders — Related Posts
Agile Failure Patterns in Organizations 2.0
Three Wide-Spread Scrum Master Failures in 5:31 Minutes—Making Your Scrum Work #1
Three Wide-Spread Product Owner Failures in 6:09 Minutes—Making Your Scrum Work #5
Three Wide-Spread Stakeholder Failures in 6:05 Minutes—Making Your Scrum Work #8
Download the Scrum Anti-Patterns Guide for free.
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
Tags: Development Team, Scrum Anti-Patterns