Discover more from Womplers
Definition of Ready – Anti-pattern #2 – Self-limiting restrictions
This post explores how a definition of ready imposes self-limiting restrictions
#2 Self-imposed restrictions
The Scrum Team consists of three accountabilities: the Product Owner, the Developers, and the Scrum Master. Refinement plays a crucial role in maintaining a healthy Product Backlog by dividing large items into smaller, manageable pieces. The Sprint Planning event provides an opportunity for the team to determine how to turn their ideas into actual solutions and the required work involved. Finally, the team carries out the work during the Sprint.
Here are a few questions:
Who does refinement?
Who does the sprint planning?
Who works during the Sprint?
If a Definition of Ready is used, who creates and enforces that DoR?
The answer to all four questions is the same; the Scrum Team does.
The same people
The very same people do the Refinement, Sprint Planning and Sprint work. The fact that it is the same people is vital to acknowledge.
If the Definition of Ready is used, the same people create and enforce that DoR. Think about this, effectively, this means the same people impose restrictions on themselves. It is akin to having a bit of work, then stopping yourself doing it with ‘I cannot start the work unit understand it’. It’s a mute argument because you can begin by understanding it.
So why the restrictions?
I have encountered this many times and have done several retrospections with teams on the topic. These are some of the expected outcomes after their discussions.
Lack of Trust with the team: In the team, past working methods have resulted in distrust among members with different skill sets, such as testers being suspicious of programmers. The Definition of Ready (DoR) is then used to safeguard and protect. This, however, does not work on building trust; instead, it anchors the distrust.
No Shared Ownership: The team has yet to fully grasp and embrace the concept of collective ownership. The inner culture of the team is more an us versus them, and not we. This topic is deep and a little out of the scope of this post.
Fear of Being Blamed: In a blame-oriented culture, the DoR is implemented to protect the team from being held accountable for missed or deviant requirements. DoR is then used to form a contract and stage gate to protect against that fear. Using the DoR will anchor and assert the need for protection against fear, leading to more dysfunctions.
Segregated Mindsets: The development team is treated as separate from the business, resulting in the utilization of the DoR to gather input from business experts before proceeding. The use of DoR inhibits the agile value of ‘Business people and developers must work together daily throughout the project’.
Stuck in Traditional Methods: Many individuals have not fully adopted the agile and Scrum ways of working and still cling to traditional stage-gated (waterfall) thinking. The DoR is effectively a stage gate which I wrote about in anti-pattern #1
One Attempt Mindset: Teams, stakeholders, and product management have a one-and-done approach and expect to succeed on their first try, disregarding the iterative nature of learning and discovery in Scrum. They then use DoR as a gate for big-design-upfront (BDUF). This thinking style is a significant issue that ripples through the software industry. Building products is more about research and discovery with feedback loops. It takes that experimentation and learning mindset. Innovating, designing and discovering a new product should not be limited to a gate to try do a complete detailed analysis and design; it defeats iterative thinking.
Lack of Team Autonomy: The teams operate more like work-order teams with limited autonomy. The DoR appears to serve as a mechanism for the team to take on a measure of ownership.
Interruptions: When businesses have no strategy and chop and change requirements or “work orders” to the team, the chaos is overwhelming and disrupting. Teams use DoR as a mechanism to limit disruption. It is easier to say, “Sorry, we cannot do that last-minute change because it is not ready.”
If you look at these are all based on the fears and anxieties of the team. To protect themselves, they use DoR. This then limits their future growth to fully embrace agility and master the art of flow and pivoting a the last second. It is a self-limiting constraint!
What to do
All the above reasons for DoR have underlying behavioural and cultural challenges. Removing them will remove the need for the DoR gate and self-limitations.
Consider a self-managing team with high ownership and psychological safety without fear of taking an idea and running with it. They show openness to a product owner, saying, “I know this is last minute, but it is critical to the business”, and the team responds, “Sure, we can run with it immediately. Let us start by figuring it out together.” This is what a “willing team and willing product owner’ is. The manifesto for agile software development encourages ‘Welcome changing requirements, even late in development.
To resolve this, you need to address the underlying concerns.
Handling the Anti-Pattern as a Scrum Master
As a Scrum Master, you will observe that DoR is often a response to protect themselves against something. When a team wants to change the framework, this should trigger your spiderman senses; thus revealing something is potentially wrong.
A team's psychological safety is vital as the lack of it will affect ownership, willingness and increased self-protection mechanisms.
Raising transparency by revealing what is happening, and facilitating a retrospection exploring the impact it has on the ability to pivot, can help your team recognise the self-limiting behaviours based on underlying challenges. This is where you will need to actively work with the team and stakeholders to work through those challenges.
It takes courage, focus, openness, respect, and commitment. With these values in mind, your team will master this element of Scrum.
I will post an article with a retrospective and a series of liberating structures that can be used to facilitate and help your team with the DoR anti-pattern. This will only be available to subscribers after another few posts on DoR-related anti-patterns.