Ready or Not Ready?

“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”
•   https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready/
•  Extreme Programming – A Gentle Introduction
•    www.extremeprogramming.org  
•  Disciplined Agile
•    http://www.disciplinedagiledelivery.com/
• Jeff Sutherland – Definition Of Ready
•    https://www.scruminc.com/definition-of-ready/
• Agile Alliance Glossary – INVEST
•    https://www.agilealliance.org/glossary/invest/
• Disciplined Agile – Agile Modeling Practices
•    http://www.agilemodeling.com/

- 

Principles for a community of professionals - II

See first - Principles for a community of professionals - I

Critical mass of potential skills

A team does not have the critical mass of potential specific skills for great steps forward or for facing too difficult problems. A single team is limited in the same way as single individual is limited. The solution is to have available a larger pool of resources: more (collaborative) teams, a community.  

Knowledge and experience sharing. Knowledge persistence

The limitations related to single team are also manifesting for sharing knowledge and experience.  Communities could be more effective in this case. Also the knowledge persistence could be more robust.

Isolated teams will have the same problems as isolated individuals: will not benefits of pre-existent or co-existent knowledge and much part of their effort will be a waste. Some examples:

• Will re-invent already existent solutions (aka “re-inventing the wheel”)
• Will be slowed by impediments that were already removed elsewhere 
• Will not re-use creative work and good results from other teams

Knowledge persistence short history: first community, temples, stories, cities, stone inscriptions, papyrus, alphabetization, academies, libraries, Gutenberg, electronic data, Internet … 

Active collaboration: inside team, between and across teams

Active collaboration between individuals it is a mandatory practice for an effective knowledge work, but is not enough. In order to get more value from skills, knowledge and experience we need an active collaboration between teams and across teams. 

Talents valorization and rare ideas

Contribution of very talented individuals, one of the engine of our civilization could not be valorized at team level – we need communities.  They need peers to develop and validate their ideas, and only a community could sustainable offer such peers. Also, only communities could spread, persist and valorize better their contribution. There were a lot of talents in the prehistory and history that have wasted their potential because of lack of collaborators and peers.

Evolving stability

All the factors enumerated here – skills, knowledge, experience, collaboration, teams and teams of teams – need time in order to manifest and bring results. A community need a time of evolving stability. For example, the history discontinuities of the “dark ages” have slow down the evolution for centuries.

Promoting valuable ideas

We cannot get value from distribution of wrong or not productive ideas. In software development, using a historical retrospective, the Waterfall approach have not produce either benefits for single projects or for software engineering evolution … with notable exception of lessons learned.  On the other hand, agile and iterative development have improved the overall results of that domain.

Historical example: The “Classical Greek” era in the ancient history was followed by a similar flourish of sciences only on the Renaissance times; this discontinuity has affected the entire evolution of the civilization.  

Different kinds of communities

It is not just a simple math. To bring together a critical mass of skills you need more kinds of communities: cities, schools, universities, specialized companies, professionals’ communities.

Inside an organization, you could benefit from communities of practice, but the first community must be the organization itself.

Creating new values, practices and new communities

New values, practices and finally new communities will emerge from existing communities.  From an economy dominated by mechanical and construction engineering has later emerged electronics and computer science.

Historical example:  The main step in evolution of human civilization was the occurrence of the first human communities. All have started in this order: first community, first series of temples (yes, first architect and first engineer have existed before first farmer), other similar communities and later agriculture and cities.

A good example - Agile Manifesto 

• "Talents realizations and rare ideas" - the "rare" ideas from initial agile methods and practices have been shared via ad-hoc community of Manifesto authors
• Share knowledge, experience and knowledge persistence - no comments needed 
• Promoting valuable ideas - the good influence over the software industry is obvious 
• Creating new values, practices and new communities - agile practices, values and principles have emerged legacy existent form of software engineering community. In fact many of these were pre-existent, but was no evolved via communities 

A good example - Software Craftsmanship Manifesto

• Has emerged from Agile Manifesto
• Address manifested weakness of  agile movement and agile teams

A bad example - Discontinuity on promoting core agile engineering practices   

• The problem was recognized by some of the main Agile contributors: Robert C. Martin, Martin Fowler, Kent Beck, Scott W. Ambler and others
• The main symptom it is so called Flaccid Scrum  (See FlaccidScrum by Martin Fowler) 
• Agile values was promoted in a diluted, partial manner 
• There was a discontinuity on promoting core agile engineering practices 
•  People skills and knowledge were "disconnected" with team-only dogma