📬 The Backlog #192
How to make meaningful adjustments to your process, what ownership means for software products (& who should take it), and what the Scrum Master’s accountabilities mean in practice.
-
Michael Küsters feels that “to make Retrospectives meaningful, identifying and enacting change is insufficient. You have to make sure that the changes are actually beneficial to the organization as a whole.”
This is a helpful line of thinking. Some teams struggle to identify meaningful adjustments during their retros in the first place. Others keep identifying them, and enacting change, without really seeing an effect of their work.
In both scenarios it’s helpful to cast your gaze into a specific direction, explains Küsters: to Optimize at the Constraint - only!
After all, the constraint determines the capacity of the entire system. Küsters’s short article shows what happens if you’re in front of, behind, or parallel to the constraint in a system, and includes practical advice.
Example: “If you’re pushing work “downstream” for other teams to pick up, and you see work piling up, do not try to discover ways to do more: Do less. Use the free capacity to pick up work that would otherwise happen downstream.” -
“The questions to answer are how to organise in teams and how to organise the software to reach a steady pace without creating an over-complicated, over-engineered or over-simplified solution,” writes Krisztina Hirth.
The topic of her article is clarity about the concept of ownership related to ways in which a software product can be improved and maintained in the long term.
(Data) Ownership, Boundaries, Contexts – what do these words mean? is recommended reading for those of us looking to help teams (re)organise themselves around the right problem, rather than an artificial or archaic product definition.
Hirth’s piece will help you articulate how that involves taking ownership - not of a complete product by a PM but of a bounded domain by a cross-functional team.
“Data ownership also means process ownership. It means the team which owns the data around “expenses”, for example, owns the features around this topic, what is implemented and when so that they are involved in each improvement or change regarding expenses from the beginning. This is the only way to respect the boundaries, take responsibility, and be accountable for all decisions around the software the engineers create.” -
During The Scrum Exchange last November, we had a conversation led by Simon Reindl about the concept of accountability.
This has evidently sparked some deeper thought in my friend Gabor Bittera, for whom something clicked into place, going by his article What are Scrum Masters’ accountabilities after all?
Originally he objected to being held accountable because “[as a Scrum Master,] how might one cultivate an environment of self-organisation, if they need to tell people what to do and how to do their jobs properly”?
Bittera re-examined the accountabilities of the Scrum Master as set forth in the 2017 and 2020 editions of the Scrum Guide. If the 2017 edition boils it down to “promote Scrum and help everyone understand it”, in 2020 there’s an added accountability; for the Scrum Team’s effectiveness.
That makes all the difference if you’re looking to (not) be held accountable. Bittera:
“So what’s changed is that after unpacking the why, what and how of Scrum, Scrum Masters are accountable to invite their teams into an environment where members can explore how to put all those teachings into practice. Thinking that you have done the needful once you have explained Scrum and leaving your team to figure it out for themselves is poor form.”
“Scrum Masters are in it for the long game, and now they are accountable for making Scrum work for their teams.” 💡
Hope you have a great 2023. Scrum on.
Thomas van Zuijlen