When faced with a choice between two implementation paths, in their relentless pursuit of delivery momentum, many teams can fall into the habit of choosing the path of least resistance. This is an easy way to preserve their momentum, which is often what management is judging them by (through either qualitative or quantitative means). While I'm an advocate of reducing scope when it doesn't jeopardise intended outcomes, always choosing the easiest pathway for implementation can cause problems in the long-term. For example, engineers often decide whether they want to build a new feature using their usual (potentially outdated) technical patterns or take the opportunity to modernise their technical approach. By always sticking to the status quo out of a fear that modernisation will come with unknowns that could delay delivery, teams are ensuring a future of technical debt and stagnation (in spite of what appears at first to be a healthy momentum). This same mindset applies to how ambitious teams are from a product innovation perspective.

By encouraging a culture of experimentation, businesses can avoid this trap. A Definition of Ready for initiatives can help with this. While today it is the norm for product development teams to have a Definition of Ready for stories and tasks, this concept is rarely extended to initiatives. By setting some basic confidence requirements before new initiatives kick off, teams can become more ambitious and innovative.

For the uninitiated, a Definition of Ready is an agreed upon minimum set of requirements that must be met on a story before it can be picked up for execution. For example, teams may agree that before they start work on a story, they must first estimate its size and agreed upon some acceptance criteria. Ratification of a Definition of Ready can be a great way to ensure a team maintains a healthy momentum: by ensuring work is always ready to be executed before it is picked up, unexpected pauses in the flow of delivery can be avoided.

This idea extends to initiatives. At a bare minimum, I believe it is critical to define intended outcomes before committing to an initiative. Teams can also lean towards more ambitious and innovative solutions by holding themselves accountable to have a certain degree of confidence in their high-level implementation plan, and making the space to experiment in advance to improve their confidence in the solutions they have in mind for future initiatives. Essentially: start with the most ambitious implementation path that is reasonable, make space to experiment (before the initiative truly begins and decisions become urgent) and use the outcomes of these experiments to inform the technical approach.