Developers Accountability in Scrum
TLDR:
Developers:
- Are members of the Scrum Team who do the work on the Increment toward the Product Goal, whether that's marketing work, legal work, business analysis, software development, or testing/verification
- Build quality in via adherence to the Definition of Done for the Product
- Self-manage
- Focus on the Sprint Goal toward the Product Goal
- Own the Sprint Backlog, and no one tells them how to do their work
- Continuously improve
- Should embrace 'fuzziness' as one can focus too much on responsibilities
A Scrum Team is a cross-functional team that practices Scrum and addresses the Scrum accountabilities of the Product Owner, Scrum Master, and Developers. Being self-managing, they decide who does what, how, and when. The Scrum Team delivers a valuable, useful, and usable Increment(s) every Sprint.
In my view:
- It could be a "layer of cake team", in that it cannot in and of itself delivery value without dependencies on other "layers" of the cake.
- The team is ideally a "slice of cake team," which can deliver value in the form of an integrated Increment.
The Product Owner, Scrum Master, and Developers solve stakeholder problems, capture stakeholder opportunities, and deliver valuable, useful, and usable improvements toward the product goal.
The Scrum Team collectively takes care of product discovery, delivery, verification, and validation toward the Product Goal. In my view, better Scrum Teams check if they "hit the bullseye" with value, tweak, or do rework to better realize the value and recheck.
Scrum Team members strive for net improvements.
Developers are Scrum Team members with all the skills and support needed to discover and deliver the Increment. They adhere to the Definition of Done and strive for net improvement. Self-managing.
In the Scrum Team, the Developers do the work and have all the skills needed to meet the Definition of Done. They are accountable for creating a plan for the Sprint, the Sprint Backlog.
The Developers are preferably dedicated to the one Product. They commit to learning and creating a usable Increment every Sprint. They create and adapt their plan toward the Sprint Goal and hold each other accountable as professionals.
The Sprint Goal is the single unifying objective of the Sprint (the why) for the team, created in Sprint Planning. The developers commit to delivering the Sprint Goal, which in my view means they will do their best, 'not move mountains.'
The Definition of Done is a commitment for the Increment. The Definition of Done describes the quality measures that express due diligence for the Developers and the Product Increment so that it could be 'delivered to Stakeholders' (including users, internal representatives, and customers).
The Definition of Done creates Transparency by describing the required state of the Increment when it meets the Product's quality measures. It typically includes both technical standards and product qualities.
If the Increment is not Done, it cannot be released or presented at the Sprint Review.
The team creates the Definition of Done if it is not provided by the organization as a minimum. If there are multiple teams on the same Product, they share the same Definition of Done.
The Increment is called an Artifact.
It is the integration of all the work completed to the standard of the Product's Definition of Done. The Increment is thoroughly verified, usable, and integrated with previous Increments.
A Sprint Review gathers more feedback on the latest Done Increment but is not a gate for release, which enables outcomes. The sum of Increments is inspected at the Sprint Review. The Increment must be usable and useful to provide value. A Done Increment is central to Scrum as it allows ongoing value validation.
The Increment is not completed until it's Done. Releases enable value, even in the same Sprint. A professional team does tidy work.
During Product Backlog refinement, the Scrum Team (sometimes only the Developers) breaks Product Backlog items down into smaller, more precise items, including description, size, and value.
Product Backlog refinement is the process of building enough understanding to have confidence that the upcoming items are ready (can be completed in accordance with the Definition of Done within one Sprint). It is a forward-looking activity that gives clarity and Focus for upcoming Sprint Planning(s).
Product Backlog refinement involves breaking down Product Backlog items into smaller, more precise, and more understood items. More details such as description, Acceptance Criteria, order, and size may be added. Attributes vary. Product Backlog refinement can involve research, e.g., the 'problem space,' user experience, and customer experience.
The team regularly refines the Product Backlog to make the upcoming work transparent. Product Backlog refinement is an ongoing activity that may be formal or informal and may include stakeholders. If Developers contribute, it can create time for more effective product management.
The Product Owner is one and only one person. The Product Owner engages with the stakeholders and Scrum Team and drives the value of the work delivered.
The Product Owner uses the Product Backlog to guide what is built and in what approximate order.
The Product Owner is accountable for maximizing value and effective Product Backlog
management. There is one and only one Product Owner and one and only one Product Backlog per Product. The Product Owner or their delegates create an ordered (sequenced) list and refine items.
With a mandate, product management skills, and domain skills, a skilled Product Owner masters the art of saying 'No'; the organization must respect their decisions.
In my view, a product manager in a multi-team setting is a Developer, not a Product Owner. This is because, in a multi-team setting, Scrum has only one Product Owner, Product Goal, and Product Backlog for the Product. In a multi-team setting, the sole Product Owner is roughly equivalent to a product leader only when they apply their product management skills and mentor product managers.
In my view, a business analyst is unsuitable to be a Product Owner as:
- Developers should participate in refining the Product Backlog.
- If this seems inefficient, try building the wrong thing a few times.
- Bad behavior arises when Developers expect perfect pre-cooked Product Backlog items
- Focus on building the right thing instead for increased effectiveness.
- Product Management skills are required.
- Scrum is only a subset of what a Product Owner has to worry about.
- This includes focusing more on the Product and emergence and less on Scrum.
- It leads to an unnecessary bottleneck, delaying clarification of the objectives or the work.
- In my career, I encountered only three business analysts with mandate and influence. The remainder were 'order takers.'
- The Developer accountability is more suitable.
In my view, Scrum Team members redeem themselves somewhat in my eyes if they take time out to:
- Identify stakeholders, what they value, who are the most critical stakeholders, and what are the most critical values,
- Identify how to satisfice a multitude of values without trying to keep everyone happy (impossible),
- Quantify objectives using Gilb's Planguage, and
- Use Gilb's Impact Estimation Tables to decide the next slice this week/Sprint
- Do the above with the support of AI tools. Perplexity is good enough with Gilb's work, but you need to understand the results to audit them); see https://www.perplexity.ai/search/show-an-example-of-stakeholder-sWhiQpd9RSGIfixHu.Q7qA for an example
- Co-ordinate amongst themselves
- Embrace 'fuzziness;' clarity of responsibilities done too tightly can lead to a lack of team ownership
Inspirations for this article (except the excerpts in italics starting with "in my view" ):
- Ralph Jocham
- Nigel Thurlow
- Martin Hinshelwood
- Jesse Houwing
- Richard Hundhausen
- Simon Reindl
- Fabio Sanches
- Dave Pryce
- Sunil Gulia
- Nader Talai
- Eric Naiburg
- Kristen White
- Stas Pavlov
- Wilbert Seele
- David L. Marquet
- Tom Gilb
- Bjarte Bogsnes
- Steve Morelidge
- Dave Snowden
- Rory Sutherland
- W. Edwards Deming
- Admiral Grace Hopper