Having a Definition of Ready: Harmful or Helpful?
Mike Cohn’s August 2016 article, The Dangers of a Definition of Ready describes certain problems that can occur when a team uses the concept of a Definition of Ready. He writes:
You can think of a Definition of Ready as a big, burly bouncer standing at the door of the iteration. Just as a bouncer at a nightclub only lets certain people in—the young, the hip, the stylishly dressed—our Definition-of-Ready bouncer only allows certain user stories to enter the iteration.
He’s right. You can think of it that way. Why you would think of it that way is beyond me. Mike worries that a formal Definition of Ready can lead to a stage-gate process. Maybe in theory it could. But it doesn’t. There’s no monster hiding under the bed.
Confusing Cause and Effect
If the organization already uses a linear process (even if they are pretending to run Sprints), and if teams are already organized into functional silos and/or around technology stacks, then they already have a stage-gate process. The use of one or another agile-style technique doesn’t “lead to” or “cause” that. It’s already established.
Below I review the LeadingAgile Compass model to try and provide context around Definition of Ready. One thing I think you’ll see is that the use of a technique such as Definition of Ready doesn’t cause problems that already exist in the organization. Instead, such practices are designed to enable the organization to solve those problems. Whether any given practice is a good idea depends on where the organization is in its improvement journey.
There’s no Magic “Agile” Switch
Many agilists are able to describe their vision of an “agile end state” for a development team that functions autonomously. Most of them are less able to define a step-by-step progression to take an organization from wherever they are today in a direction toward that “ideal” state. A team is either “agile” or “not agile.” Most agilists speak of a journey, but then they teach and coach as if there’s a magic switch you can flip.
Organizational improvement is a process that usually takes time and effort, and mindful step-by-step progress. In the early stages of that process, Definition of Ready can alleviate the effects of certain organizational issues. That doesn’t mean it’s a magic technique that should be used forever, and always in the same way. The other side of that coin is that it isn’t a “bad” technique that should be categorically dismissed.
In a Perfect World
An “agile” team operating in a supportive organization can do pretty much anything. A Definition of Ready would probably be a hindrance to them. By definition, the canonical agile team has complete control of the end-to-end delivery process, from collaborating with key business stakeholders to determine the highest-value features to be delivered, to creating the environments and deploying the code. They have no (or very few) cross-team dependencies. They have no hard hand-offs.
As the old song goes, “It’s nice work if you can get it.”
Or, Maybe Not so Perfect
The song goes on to say, “…and you can get it if you try.” The word “try” implies a lot, in this context. It’s a bucket that contains customer collaboration, the time-boxed iteration, the daily stand-up, the backlog, the retrospective, the iteration review, the customer demo, the Three Amigos, the Definition of Done, automating “all the things,” the Extreme Programming practices…and yes, the Definition of Ready, too.
It isn’t a big burly bouncer guarding the door. It’s a tool for helping a team move forward from one level of proficiency to the next. Definition of Ready isn’t a wall between stakeholders and delivery teams; it’s an invitation and a template for collaboration.
“Agile” Isn’t the Point
If you will indulge me in using a metaphor for a moment: I sometimes liken Scrum and similar methods to Forrest Gump’s braces. At one point in Forrest’s life, he needed the braces just to stand and walk. When the time came for him to run, the braces fell away piece by piece. Continuing to wear them at that point would have held him back.
Most of the practices associated with “agile” software development, and especially those associated with the Scrum framework, are in the nature of Forrest Gump’s braces. At first, teams require a lot of support and help to change their habits and to get used to a way of thinking and working that may be quite unfamiliar to them. At the same time, the system in which the team operates (that is, the organization) has to be conditioned to operate consistently with agile thinking. As the team and the organization progress in their joint “agile” journey, the supporting practices can fall away one by one.
From a Lean point of view, all the canonical agile practices and events and ceremonies and what-not are overhead. No customer explicitly pays for us to do any of those things. They only pay for the end result. Rather than striving to perfect our daily standups and our sprint reviews and our definitions of Done and Ready, we should be striving to make them unnecessary. We can’t just dump the practices arbitrarily; we have to earn the right to dump them by demonstrating the ability to deliver without them. Before we can discard our braces, we have to stand, then walk, then demonstrate that we’re ready to run.
When is a Definition of Ready Useful?
The Definition of Ready represents a shared understanding of the state the work must be in before it can proceed to the next set of activities on the way to Done. It’s helpful whenever more than one team has to be involved in moving work through the delivery pipeline to Done.
Given a pristine agile team operating in a pristine agile organization, there’s no need for Definition of Ready because the single team handles all aspects of delivery. It’s only useful when different people handle different aspects of delivery, like strategic planning, requirements elaboration, architecture, design, coding, testing, packaging, deploying, infrastructure management, production system monitoring, operations, and production support.
The best way to feel confident that you have a shared understanding is through direct collaboration. So the goal of establishing a Definition of Ready actually drives collaboration.
LeadingAgile works with many larger, established organizations that are a long way from that pristine agile model. These organizations have grown over time, both organically and through acquisitions. Usually based on a utilization mindset, they collected similar skillsets and tools into specialized functional silos, thinking this was the way to achieve efficiency.
In fact, efficiency is achieved by focusing on throughput rather than utilization. Value-producing steps, resources, and people have to be aligned with the value stream.
In an organization that has multiple products and services as well as back-office support functions, this can translate into multiple operational models in use simultaneously in different parts of the organization. The simple, canonical, pristine agile team model is not sufficient. It may not even be possible.
Our Compass
I’d like to use the LeadingAgile Compass model and mountain-climbing metaphor to put some context around the idea of Definition of Ready. The compass is really a quadrant diagram drawn as a circle so we can call it a compass, to go along with our mountain-climbing metaphor. Pretty clever, eh? Yeah, I think so, too.
Here’s one view of it:
The model illustrates organizational values on the horizontal axis. Predictive means the organization seeks to meet commitments predictably and accountably. Adaptive means the organization seeks to establish the ability to adapt to change.
Customer-driven values are shown on the vertical axis. Convergent means that customers know what they want. The organization’s efforts converge on the delivery known capabilities and requirements. Emergent means customers need the organization to explore possibilities and discover solutions. The organization’s efforts emerge valuable solutions for customers.
Uncertainty and the Compass
Alexander Laufer and others examined the effects of uncertainty in construction projects back in the 1990s. They identified two types of uncertainty: Means uncertainty and enduncertainty.
Means uncertainty means that we know what we want, but we aren’t sure how to get there from here. End uncertainty means we have a vision or concept or capability in mind, but we aren’t sure what kind of solution will realize that goal.
The canonical agile team model and canonical agile methods are designed to deal with means uncertainty. They work well in an organization that operates in the Adaptive-Convergent quadrant. That is, the business goals and probably the “requirements” for any given software system are known: efforts are meant to converge on that solution.
Meanwhile, the way to the goal is uncertain; we need frequent feedback and course corrections to arrive at the destination.
So we have the idea of the time-boxed iteration, what Scrum calls a Sprint, in which delivery teams burn down a list of things to do, usually called a “backlog”.
Somebody knows what is supposed to be in the backlog and is responsible for keeping it up to date. The team collaborates with that somebody to refine backlog items that are coming up in the near future. The iterations provide time markers for feedback and course correction. The iterations are the same length, which provides predictability for planning, review of work in progress, stakeholder feedback, and process improvement.
That works well for operations that fall into the Adaptive-Convergent quadrant.
But we rarely find organizations that are already positioned to operate that way.
For organizations in the Predictive-Emergent and Predictive-Convergent quadrants, the canonical pristine agile team model is just too difficult. It goes against the grain of the organization on a deep level.
For organizations in the Adaptive-Emergent quadrant, which is basically the Lean Startup idea, the same model is regressive and would slow them down without adding value.
Organizations in the Adaptive-Emergent quadrant have end uncertainty; they’re probing the market continuously to identify what they need to do.
Canonical agile methods don’t help in this situation because there’s no practical way to establish a backlog. What’s needed is more like a series of experiments and the ability to pivot quickly at low cost.
Definition of Ready doesn’t make much sense in that situation. But neither do concepts like a backlog, a time-boxed iteration, or a ScrumMaster. It’s the whole canonical agile model, and not just one technique in isolation (such as Definition of Ready), that doesn’t fit here.
So, given the compass model, let’s consider what kinds of organizations might benefit from something like a Definition of Ready.
Starting Point in Larger Organizations
Large organizations typically begin in the Predictive-Emergent quadrant. This is not really a viable operational model. It is chaotic, and not in a potentially good way like in the Cynefin model, but just plain old chaos. Lack of control. No one really understands what’s going on. They’re trying to discover emergent solutions using methods that depend on understanding requirements up front.
For those organizations, we start by moving toward Predictive-Convergent. Even if their goal is to operate in the Adaptive-Emergent quadrant, and it looks as if it’s right next door, there’s no straightforward path directly to that destination. The organization has to learn how to get there step by step.
We guide the organization toward the Predictive-Convergent quadrant; toward a level of capability we call Basecamp 1. The goal is to become predictable, dependable, and accountable in making and meeting commitments.
Large organizations begin with teams structured around functions and/or technologies. They’ll have a design team, a testing team, a network team, an infrastructure team, a database team, and so forth. Teams are not aligned with value streams or product lines. To get a piece of work through the delivery system, several or many teams must touch the work. No single team has a comprehensive view of or full control over all the activities necessary to complete the work.
Managing Cross-Team Dependencies
Under those conditions, when a team receives partially-completed work, that work has to be in a state that the team can act on. Otherwise, the work has to go backward and be revisited by one or more upstream teams before further progress can be made on it.
These back-flows are one of the reasons the organization can’t meet commitments in a predictable way. The siloed organizational structure is one of the reasons it’s hard to find anyone accountable for anything that happens.
The Definition of Ready is one of the tools we can use to mitigate the effects of the organizational structure, which is not aligned with the value stream but rather with functional silos that have to hand the work off to one another many times in the course of completing a request.
With regard to accountability, the Definition of Ready helps all interested parties understand where certain things happen in the delivery process, and who is responsible for those things. In most cases, this information is not known beforehand; everyone in the organization only knows about their piece of the action. We often find that no single individual anywhere in the organization has a comprehensive understanding of how things get done.
The Braces Fall Away Piece by Piece
As organizations, or parts of organizations, progress from basecamp to basecamp, they are generally moving across the bottom half of the model from Predictive-Convergent to Adaptive-Convergent, and if business needs dictate it, up to the Adaptive-Emergent quadrant.
On this journey, the Definition of Ready helps teams collaborate to understand one another’s needs, as well as to clarify accountability and to identify opportunities to simplify the organizational structure and streamline the delivery process.
The level of formality can be reduced gradually as the organization matures, in the same way as other overhead activities can be relaxed once the organization learns better ways to achieve the same goals.
So, Definition of Ready is not a mechanism to isolate teams and frustrate collaboration. Quite the opposite. It’s a tool that adds value at certain stages of the journey, when it is applied properly and for the right reasons.
Nor is it something we want to lock in place forever. When the organization outgrows the need for it, the formal Definition of Ready can be simplified and possibly eliminated.