This week, a Business Analyst asked me what I thought of a team having a Definition of Ready, and as so many of us do, he baked some answers into the question he asked me. He mused that it could be considered a useful and recommended practice but is probably something to avoid because it’s overly prescriptive and perhaps a collaboration killer.
My response was simple, and I thought it was obvious. A DoR can be useful in the early days of changing to agile ways of working from something else but should generally be considered an anti-pattern that's symptomatic of something that needs solving.
I thought this answer might need a bit of expansion, as I typically give broad, sweeping statements as a first response to questions. I enjoy the confrontational nature of doing such a thing and find the questioner will often clarify what they were asking when confronted.
I didn’t expect this to be a surprising answer, though.
I thought the community had a more general understanding that this is an anti-pattern.
Apparently not.
I received a string of questions in return, but the essence of what I was now being asked was:
Is the mere existence of DoR an anti-pattern because refinement or conversations aren't happening well?
I felt this needed a return to basic principles about how an agile / Scrum team is meant to work on a problem.
A DoR is an anti-pattern because it assumes that some part of the value generation has to be completed before the Scrum team can start working on it. If the Scrum team cannot deliver the entire solution to the problem they've received, they are working in a waterfall environment.
For a software development team, the anti-pattern could arise from a Scrum team, not including someone who can fulfil the UX or design element of the work and, therefore, depends upon another individual or team delivering their slice of the work before they can deliver theirs. The solution here would be to form a truly cross-functional team that can be handed a problem and work through the entire double diamond (from design thinking) to discover, define, develop and deliver the solution.
Unfortunately, there is a misconception that User Stories (or whatever task goes into a team) are only for software engineers who are confused with the Scrum term of Developer. The Scrum Guide defines Developers as the people committed to creating *any aspect* of a usable increment.
In other words, Developers in a Scrum Team must include anyone and everyone who works on a given problem to create a valuable solution.
Given the above, there is no need for a DoR because no work is done outside of the Scrum Team or outside of the Sprint.
For a team that has moved to Scrum, when an organisation has iterated itself far enough through a transformation that Scrum Teams are truly cross-functional, the DoR would become redundant.
Well, I blew his mind with this analysis…
He started considering the problems these ideas cause many Scrum teams. He started to question if it’s ok to abandon the idea of a Scrum team and, if so, what is lost and what are the consequences of doing so.
Perhaps this reflected his experience. He had basically accepted agile as something gated.
In my experience, most Scrum teams I've met aren't even close to being Scrum teams. I would credit this with why there's so much hate for agile / Scrum in the software engineering community and so much chatter about whether or not agile is dead more generally.
For most people in most organisations, Scrum is just a veneer of extra overheads on top of their pre-existing, mechanistic workflows rather than the enabler of self-organising, self-managing, highly creative and adaptable teams.