“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 :
If you believe that your are in-time, you are in fact delayed.
If you are already delayed, you are in fact much more delayed.
If you want to be in time, you need to be ahead.
References/Links
- Mike Cohn – “The dangers of a definition of ready”
- Extreme Programming – A Gentle Introduction
- Disciplined Agile
- Jeff Sutherland – Definition Of Ready
- Agile Alliance Glossary – INVEST
- Disciplined Agile – Agile Modeling Practices
-
No comments:
Post a Comment