Why Inexperienced Teams Shouldn't Start With A Definition of Ready
Complex work means not knowing and dealing with surprises. You're not supposed to feel ready because you're never ready!
I recently posted this meme on LinkedIn as a joke to make people think:
Of course, life isn’t black and white. The Definition of Ready exists on a whole spectrum and has its uses in specific situations. I presented a false duality for the Definition of Ready (DoR) to stir discussion.
Interestingly, many people in the comments claimed that a Definition of Ready is great for inexperienced teams but is usually removed or downsized as they become more experienced.
Here is a selection of anonymized comments from my post to paint a picture of the ‘Definition of Ready is great for inexperienced teams’ sentiment:
“As they gain experience and improve their way of work, they realize that all that information upfront is not needed. That the majority of the information they used to need upfront (to feel safe) either doesn't match the reality (what's in the code, in the case of software) or is a waste of time and effort.”
“When in Shu, I'd recommend a DoR, a lightweight one. In Ha - up to the team. in Ri - don't need it”
“For low-maturity teams with a track record of “building the wrong thing “ and a lack of continuous discovery habits, an explicit policy to avoid the build trap can be a good scaffold that can be removed.”
I have the opposite opinion. I believe it’s a bad idea to get inexperienced teams started with a Definition of Ready. I want to stress that I’m sure there are cases where a Definition of Ready is beneficial, even for inexperienced teams. Though I have to admit I haven’t personally encountered them while I’ve worked at many start-ups, scale-ups, and corporations.
I actually think the lack of experience is a strong argument for not using a Definition of Ready. There may be other, stronger factors at play that rule in favor of a Definition of Ready, but if the only factor is lack of experience, then I would not start such a team with a Definition of Ready.
I believe the Definition of Ready is a band-aid you should try not to start with because it covers up the mindset you must have to succeed with Complex work. Let’s explore why I believe inexperienced teams should usually not start with a Definition of Ready.
Complex Work Requires Balancing Coordination and Collaboration
When you have an inexperienced Scrum Team, they’re usually unaware of the difference between Complex and Complicated work. And even if they are, that doesn’t mean they have the right mindset yet or have adopted the appropriate practices depending for dealing with Complex work.
Doing Complex work means finding the right balance between Coordination and Collaboration. That means - Doing the right thing together in the moment as you discover and learn what’s necessary vs. trying to predict and plan based on your knowledge and expertise.
For succeeding with complex work, it’s crucial to strike the right balance between hindsight and foresight. The biggest reason teams get this balance wrong is that what makes you successful in the Complicated domain is actually an anti-pattern in the Complex domain. The usual approaches that set us up for success in the Complicated domain make us more likely to fail in the Complex domain.
Imagine you’re doing Complicated work, and you discover your plans suck. You didn’t spend enough time predicting, planning, and coordinating. Perhaps you lack the expertise in your teams to make adequate predictions and plans. You solve the problem by hiring the right expertise and spending an adequate amount of planning. Now your plans will rock!
Alternatively, let’s say you’re doing Complex work, and you discover your plans suck. You draw the same conclusion as in the Complicated domain. You have to spend more time predicting, planning, and coordinating. The line of thought is perfectly reasonable - spend more time planning and predicting and your plans will be better.
Except in the Complex domain, this sets you up for failure. All that additional prediction, planning, and analysis inject noise and speculation into your plans. Congratulations, you only invested effort to make your plans suck even more!
This approach is extremely common. At many companies, it results in the Planning Cycle of Madness:
We fail to meet our plans, roadmaps, and timelines. Our plans suck. We need to do a better job at planning.
We do more meetings, planning, analysis, design, and up-front coordination. We overfit our plans by injecting noise and speculation. Our plans become disconnected from reality and rooted in our imagination.
Our plans act as an anchor that stifles the ability to collaborate and adapt. We become locked into plans that drag us down by preventing collaboration, learning, and discovery.
Surprise! We fail to meet our plans, roadmaps, and timelines. and then usually, what happens is that they keep repeating the cycle hoping for a different outcome that never happens.
By now, you might be thinking I went off on a tangent and began to wonder: how does all this planning lunacy relate to a Definition of Ready?
In inexperienced Scrum Teams, the balance between Foresight and Hindsight is usually off. There is too much focus on Coordination and too little focus on Collaboration. These are the teams that are more likely to want a Definition of Ready and end up in the Planning Cycle of Madness.
Teams that rely too much on Foresight and Coordination will not succeed with Scrum. They will overfit their plans and inject speculation, making everything more difficult. That’s why it’s super important to promote Collaboration in inexperienced Scrum Teams.
Complex work means no matter your amount of experience or expertise that you will have surprises that you have to deal with. And it’s usually the ability to adequately deal with surprises that determines how successful you will be with Scrum. We’re pretty good at the planned work compared to dealing with surprises, especially if we need help from other teams. And that’s why you have to promote the ability of Scrum Teams to act in the moment from the get-go to help team members and teams make the right decisions on the spot as they discover and learn what’s necessary.
Dealing with surprises will make inexperienced teams uncomfortable and make them think: should we do more planning? Should we do more analysis? Could we have caught this? And these are all fair questions. But when those teams adopt a Definition of Ready, they usually limit their Collaboration to keep up the illusion of Coordination.
The ability to deal with the unexpected and handle surprises is usually much more cumbersome for teams. And that’s why that’s where we should invest more effort from the start. Get them out of their comfort zone to deal with surprises and be flexible to what unfolds as they do the work. Even if it results in a bit more mess that could have been prevented.
The Definition of Ready may help prevent surprises, but it may also prevent the team’s ability to respond to changes and learn how to deal with surprises effectively. And that’s the make-or-break factor for dealing with complex work that many Scrum Teams are pretty terrible at.
The Ability to Deal with Surprises Is More Important Than To Try To Prevent Surprise
Teams are usually much better at trying to prevent surprises than dealing with surprises. That usually boils down to their mindset - how much they believe they can know before starting the work. Teams that overestimate how much they can know before starting will have a rigid and extensive Definition of Ready.
What happens to work that encounters a Definition of Ready? It usually gets delayed. Sometimes for a short period of time, and sometimes over many Sprints. And that’s the right decision if the team cannot complete the work by starting on it. However, if the Definition of Ready delays something highly valuable they could have completed sooner, e.g., a shopping cart speed improvement worth 10K per day, who cares if picking it up goes a bit sloppier than expected?
In such a case, the Definition of Ready can cost you a lot of money. Especially with inexperienced teams that have a Definition of Ready that’s too rigid and doesn’t respect the nature of the work - there will be surprises.
Remember, we’re not doing assembly line manufacturing work. What you don’t know matters as much as what you do know. The only way to discover what you don’t know is by rolling up your sleeves and working with what you do know. Our job is to help our teams feel more comfortable with everything they don’t know before starting.
Inexperienced teams overestimate what they believe we know. They will also have a Definition of Ready that prevents rolling up their sleeves in many situations where it would have been best to do so. And that’s why I believe it’s usually not in your best interest to start with a Definition of Ready.
Success with Agile and Scrum means you need to grow the ability of teams to collaborate, adapt and deal with surprises. I prefer to cultivate this mindset from the start and get the team out of their comfort zone to improve their ability to collaborate, as that will be far more important in the long run. Especially when more teams are added and inter-team collaboration becomes even more important.
That’s why I believe lack of experience is a strong argument for not using a Definition of Ready.
If you still want to use a Definition of Ready, at least call it a Guideline of Ready. If your platform goes down, it’s likely somebody will start working on it after being provided with just a title and little other information to go by. Nobody will stop the work because it doesn’t meet your Definition of Ready. Sometimes a title is all it takes, and the rest you must discover as you do the work.