Should Agile Teams Have a Definition of Ready?
In The Dangers of a Definition of Ready, Agile thought leader Mike Cohn expresses a concern that is shared by many in the community: That by establishing strict rules about what information must be provided before a development team can take on a backlog item, we risk backsliding into a linear process model.
It is a truly terrifying prospect!
Oh, wait. I was thinking of something else. It isn’t a terrifying prospect. It’s actually a non-issue.
It would be stupid to expect a team to start work on an item that isn’t defined. Just tossing a vague statement into the ether and attaching an arbitrary due date doesn’t work. It never did.
The idea is to collaborate with stakeholders to make sure the backlog item is in proper shape to enable people to complete it. The idea is not to build a wall between the team and stakeholders. It’s a basis for collaboration, not a substitute.
This concept seems to be difficult for many people. For example, Michael James, commenting on Definition of Ready on Scruminc.com in August, 2017, wrote, “The statement ‘Some companies actually require a detailed checklist to determine whether a story is Ready Ready,’ illustrates why prescribing the Definition of Ready practice usually violates the Agile values and principles.”
These concerns remind me of something that happened many years ago when I was working for a State government. A person who worked in the same building was blind. One day, he wanted to attend a conference for blind government employees. The State issued him a car to use for the trip. They issued the car directly to him. They did not provide a driver. When he inquired, the reminded him that his wife was not allowed to drive the car, as she was not the person to whom the car had been issued. They knew he was blind, but there were no rules for that case. He met all the criteria stipulated in the rules for using a State vehicle. They handed him the keys with a smile and (he assumed) a wave.
It’s true that you’re free to use the same level of common sense with respect to your Definition of Ready, if you choose. You’re free to hit your thumb with a hammer, too.
Comments (2)
Jardena
Great article Dave! I think people confuse agreements with rules. If the Definition of Ready is a team agreement, they can change the agreement when it no longer serves them! If it’s a corporate rule, well that’s going to cause all kinds of problems, at best a linear process model but at worst a totally disempowered team.
Without a definition of ready, teams have unnecessary churn and conflict because they are chasing readiness.
The definition of ready is just an example of aligning the team on a decision-making framework. Usually a good thing.
Dave McCraw
Not sure you’re really addressing Cohn’s point here. He highlights the danger of “establishing strict rules”, and your suggestion is also to not have strict rules (“just” use common sense)?
It’s just about axiomatic that the kind of organisation which is considering a formal Definition of Ready is at high risk of dysfunction. I’ve seen many instances where the reality of DoR (or DoD) is a territorial exercise on behalf of some central function to control the entry (or release) of work; counteragile.
If you can avoid any perverse outcome by using common sense, pretty much any methodology will work just great.