Two dimensions: Just in time and Envisioning

A paradox?

In the previous post (JIT – Just in time and Software Development) I have discussed the importance of JIT approaches in Agile Development. In fact, JIT mean adaptive and that it’s “synonym” with Agile. Anyway, no human endeavor can be 100% adaptive. There is also another dimension, related to need of envisioning. Software development it is, by its nature, a “design” activity, where design, also by its nature, it is an envisioning kind of activity. We have an apparent paradox here: Software Development it is both JIT and envisioning by its nature.  In fact it is not a paradox, because design-envision and JIT-adaptive could be unified when we tailor the process in context (see also Adaptive Design)

Paradox: by its nature, software development suppose both JIT and Envisioning

Why we need envisioning – Agile practices

We need envisioning for any human endeavor, but here are some needs related to the software development:

• A software solution – design and architecture tell us that we have a valid solution, we are ready to plan the work and then ready start that work.
• A software release – (in Agile: rather small releases) must be delivered in time for the target business needs and that need envisioning: for requirements, envisioning  for solution (design and architecture), costs, time, resources and other plan elements.
• Lean! – looking ahead could

More concrete, let’s see how the mentioned Agile practices have envisioning as a purpose:

• XP – Architecture Spikes help to reduce the risks related to solution and also help to estimations. System Metaphor will help everybody to understand the system, even the new people
• Scrum – Product Backlog it is just an envisioning of incoming work! The backlog refining it is just a clearer envisioning of that work.
• DAD – We have here a clear support for envisioning a software release by explicitly Scope exploration, Architecture Envisioning and stakeholder’s agreement on the vision about solution delivery.

A very interesting DAD practice it is Look Ahead Modeling, that opportunistically envision some requirements and solutions parts. It is similar with Refining from Scrum, but is clearer about the intent and more effective on dealing with future communication risks. Another improvement that come with DAD, it is the concept of consumable solution: it is a better definition of Done, that will make any envisioning effort more effective.

More (on DAD): the explicit models of the possible development/delivery life-cycles make clearer the used ratio between envisioning and JIT:

• Agile and Lean life-cycles
• Continuous-deployment – where the context “force”  a JIT approach
• Exploratory life-cycle – where the context “force” envisioning

Should be observed that the two approaches must be balanced and in the extreme cases we must be very careful with applying the elements of other dimension:

• Continuous deployment – it is a permanent JIT, but is not only JIT. Product Backlog and Look Ahead Modeling will be here extremely useful to envision/refine the incoming work and make continues deployment more effective.
• New product on the market – seems to be 100% envisioning, but that suppose very high risks and break the rules of managing high complexity. Using the DAD Exploratory Life-Cycle, we will introduce more feedback loops and we will have in fact a sequence of smaller releases, that mean we balance somehow to the JIT side.

Two dimensions: Just in time and Envisioning

Distinct dimensions will always coexist, we cannot choose between them, but only adjust to to the proper balance . Let’s re-formulate some rules of JIT together with the ones of envisioning:

 Do not make guesses about incertitude.

You cannot “compute” something that is too complex.

Context introduces incertitude and complexity, but also some constraints for envisioning and visibility. According to the context, should be used a valid, balanced, adapted combination of envisioning and JIT.

Increase visibility (“readiness”) by removing the incertitude and complexity on various levels of incoming work: product, release/project, iteration and further.

Each transition from incoming work to the work in progress suppose a proper degree of readiness: product to release, release backlog to iteration backlog, iteration backlog to tasks.

The “Ready” to work state introduced by Scrum, it is in fact the effect of envisioning (where Scrum use the term /practice of “refining”) of the incoming work, but should be re-think in order to be applied on more levels, not only for the iteration start. A definition of “Ready” for starting the Construction in a release/project could be found in DAD and it is represented by the elements of the Inception part, responsible with envisioning. The “Proven architecture” milestone it is a validation of this “Ready” for (continue) Construction.

In a 3D space, we cannot choose to live in 1D or 2D