Agile &: 08/15/16

“Ready” is dangerous ?

Ready is a Scrum concept much less known than Done, but not a less important one. It is less known, because Scrum authors have very little to say about that in the Scrum Guide. Instead, “Ready” it is concept very used by Jeff Sutherland to demonstrate competitive advantage of Scrum, in optimizing the work and getting velocity. You can find more about Jeff Sutherland “definition of ready” here. In a very short summary, Ready mean:

Clearly understanding for what should be done
Clarity about business value to be used for prioritization
INVEST criteria for user stories
Free from external dependencies

Scrum (guide) propose an explicit Definition of Done (DoD), but not also that of Definition of Ready (DoR). More, Mike Cohn, one of the co-founders of the Agile Alliance and Scrum Alliance warns in a recent blog post, about the “danger of a definition of ready”. What are these dangers (…please read the post to avoid my possible misinterpretations)? Quotes:

“A Definition of Ready Can Lead to Stages and Gates” (read “waterfall”), “when a Definition of Ready includes a rule that something must be done before the next thing can start”. “That’s why, for most teams, I do not recommend using a Definition of Ready. It’s often unnecessary process overhead. And worse, it can be a large and perilous step backwards toward a waterfall approach.”

Mike Cohn propose two solutions (quotes):

“Agile Teams Should Practice Concurrent Engineering”, “in which the various activities to deliver working software overlap”
“Using a Definition of Ready Correctly”: to prevent gates and stages, use guidelines instead of rules for DoR

I completely agree with these proposals, and with the existence of the problem, but not also with the definition. There are two other much bigger problems:

Using Scrum always put many teams in the danger of sliding back to Waterfall because of too few software engineering guidance
Definition Of Ready it is always useful when we have a good software engineering practices and guidance

Waterfall Danger when using Scrum

Big Up Front - Too much details in the Product Backlog Items is definitely Big Up Front work for: requirements, solution and planning. There is too few guidance in Scrum about engineering activities that could be done during “vision” or “refining”. As a result, many team will do too few or too much for these parts. Other Agile Methods have clear guidance to avoid both mistakes:

XP – Extreme Programming come with Architectural Spikes and Solution Spikes. Yes, folks, true agilists will really start coding during the “vision” and “refining”. That is one of the first thing do to envision, to look ahead into solution risks and (…as Mike Cohn said) to overlap various kind of activities
Disciplined Agile come also with Requirements Envisioning, Architecture Envisioning, Look Ahead Modeling, and Just Barely Good Enough. Both Architecture Envisioning and Look Ahead Modeling could contain spikes, but also models or free discussions about the solution.

Neither Big Up Front nor No Up Front were a solution for domains such software engineering. We need a proper balance between envisioning and just in time approach. The first example is the XP practice of architectural spikes clearly recommended before release planning and in the first part of a release. Same approach must be done for requirements, because, of course, we have nothing to architect or spike if we have not have gather some requirements.

Sliding Big Up Front or to No Up Front is default problem for Scrum, because has too little guidance about a risks-driven approach, considering the release life cycle or concrete software engineering activities. Disciplined Agile (and partially XP) have solved this problem by guidance and practices.

Here is a possible example of mixing activities and practices during the development:

Practice	Vision	Before Iterations	During the iterations
Requirements Envisioning	High	Sometime	Sometime
Architecture Envisioning / Architectural Spikes	High	High	Sometime
Solution Spikes	High	High	High
Look Ahead Modeling	High	High	High
Model Storming	Sometime	Sometime	High
Pair Programming	High for spikes	High for spikes	High
Barely Good Enough	Always	Always	Always

When envision, look ahead or spike there is no danger for either Big Up Front or to No Up Front. Teams are free to adapt the usage of these practices in the context of a concrete release.

“Ready” could be always useful

I come back to the Jeff Sutherland definition of ready: (quote) “Jeff walks through Ready criteria - the importance of having a story in an actionable state, estimated at the right size, prioritized to Business Value.”. The main question is what want to get Jeff Sutherland with the readiness? He wants to optimize and improve the work during the Sprint, by obtaining faster a better Product Increment. If, for example, we are stopping the work during the Sprint/Iteration to wait for some important clarifications from the Product Owner that is not available, that is pure waste. It is always useful, for example, to have a “buffer of clarifications” to avoid such problems.

For me, it is an absolutely waste-producing approach, to have no clarifications before the iteration start and to try to find almost all about the requirements and solution during the Sprint/Iteration planning:

The discussions between Customers-Product Owner-Development Team should be rather “iterative” and cannot put it in fix sequence: Customers-Product Owner before iteration and Product Owner-Development Team inside iteration. We need instead to Look Ahead before iteration.
Spikes and Architectural Spikes does not fit (only) in the small period of a Sprint Planning

With a proper practices and guidance and with a team that tailor its process there is no danger of waste, or of Waterfall (by a Big Up Front approach or by a gate approach):

Intention of Ready is to avoid waste resulted from waiting or from misunderstanding during the biggest amount of work (Sprint work, excepting refining). It is intention, not a stopping gate.
Using the right practices, with a right granularity during vision and refining: Spikes, Look Ahead Modeling and Barely Good Enough

As a conclusion … If you want the performance and velocity promised by Jeff Sutherland by “implementing” a “definition or ready” and avoid dangers evoked by Mike Cohn, then, you can complement the lightweight Scrum with practices and guidance from XP-Extreme Programming and DA-Disciplined Agile.

As I have write in a previous post :