Tag Archives: Disciplined Agile

Two dimensions: Just in time and Envisioning

Leave a comment Posted by on January 25, 2015

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

Adaptive Design , , , , , , , , , ,

JIT – Just in time and Software Development

Leave a comment Posted by on January 18, 2015

(See also Part 2 – Two dimensions: Just in time and Envisioning)

JIT – solution for incertitude and complexity

Driven forces that introduces JIT Life-cycle in software development

  • Business side: often changes – it is too complex to perform (too much) ahead requirements gathering
  • Development side: software solutions are mostly design (instead of production) it is too complex to manage big chunks

As a consequence of the degree of incertitude and complexity for both requirements and solution, the life-cycle (planning) that suit better will have a JIT model. Agile development has adopted from the start such approach in its principles and practices: often and small releases, iterative development.

JIT approach it is a solution for dealing with incertitude and complexity.

JIT approach it is a solution for dealing with incertitude and complexity. It is similar with the mathematical approach to solve non-linear problems: feedback based approaches (control theory).  The main issue is that you cannot compute (in mathematics) something that is too complex. In software development that mean you cannot envision too much requirements, solution and plan because of incertitude and complexity.

You cannot “compute” something that is too complex

Agile is one of the development approaches that already use JIT for more aspects. We can observe that XP that use “small releases” approach, use also “simple design” principle/practice – they do not want to make guesses about possible solutions aspects, required by possible future change request.

Let reformulate some JIT aspects:

  • do not make guesses about incertitude (what is difficult of impossible to clarify)
  • do not try to “compute” too complex problems

Do not make guesses about incertitude

If these principles are not follow, we will have the same problems as in mathematics: huge deviations of the solution for small changes in the inputs. Translating to the software development that mean huge waste.

JIT and Agile

Some Agile principles and practices that already use JIT approach:

  • “Responding to change over following a plan” (Agile Manifesto – value)
  • “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” (Agile Manifesto – principle)
  • “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale” (Agile Manifesto – principle)
  • “Business people and developers must work together daily throughout the project.” (Agile Manifesto – principle)
  • “Make frequent small releases.” (XP rule)
  • “No functionality is added early.” (XP rule)
  • Simple design (XP Practice)
  • Model Storming (Agile Modeling / DAD – Disciplined Agile Delivery practice)
  • Document late, document continuously (Agile Modeling / DAD practice)
  • Active stakeholder participation (Agile Modeling / DAD practice)
  • Just Barely Good Enough (Agile Modeling / DAD practice)
  • Explicit support for JIT based life-cycles: Agile, Lean, Exploratory  (DAD – Disciplined Agile Delivery)
  • Inspect and Adapt (Scrum principle)

JIT – main difference versus manufacturing

We need to deal with the main difference versus manufacturing: JIT design versus JIT production. In manufacturing we repeat the solution (design) from the last life-cycle and in software development we need to find a new solution for the newer requirements (metaphor: the market request every time car with a new design). The major problem here is to integrate the previous simple design with the current simple design (there are not just additive). We need that:

  • The existent design must be easy to extend
  • Integration of “next” design must be quick, easy and clean

I have described a solution for this problem in a previous post, a solution that re-arrange some already know thinks from XP and Refactoring (as it was defined in the Martin Fowler book) –  an Adaptive Design based on this rules:

  • Use simple and clean design and then adapt for new changes (example of adapt “tool”: refactoring)
  • Use design practices that increase the adaptability (Refactoring, TDD, Clean Code, Clean Architecture)

JIT production from manufacturing it is based on responsiveness of a highly automated production. JIT design from software development it is more difficult to be automated, but we need to find that solution for responsiveness – it is mandatory to have an Adaptive Design.

Summary

  • JIT approach it is a solution for incertitude and complexity, that it is validated also in mathematics
  • Software development main problems are related to incertitude and complexity, that mean JIT approach could be useful in various ways
  • JIT rules: do not make guesses about incertitude, do not try to “compute” what it is too complex
  • There are many Agile values, principles and practice that are based on JIT approach
  • JIT Design require an Adaptive Design
Adaptive Design, Practices , , , , , , , , , ,

A product it is … not a product.

1 Comment Posted by on December 8, 2014

What does MVP really mean…? (MVP – Minimal Viable Product)

That is a very interesting question. A first idea is to thing to the customer business needs: what are the minimal set of features that are needed and have relevance to be deployed first.
In fact, with this first delivery, we are initiating an ecosystem, where:

  • a business relationship with the customer(s) it is born, where the development side mus be able to follow the customer needs on short, medium and long term with good enough cost, quality, responsiveness and other possible attributes
  • the economics of this business relationship must be good enough for both sides
  • the development side must be able to find continuously effective and efficient technical solutions
  • the development side must form and maintain a product team with enough skills, maturity and availability to serve the customer needs
  • the process approach must make sure that enough business side feedback it is included in the product in order to make this product fit for the target business. Also the product must have such properties and included support in order to be  a consumable solution (DAD – Disciplined Agile Delivery concept)
  • the initiated approach must produce repeatable results (DAD principle)

…conclusion…

A Minimum Viable Product it is in fact a Minimum Viable Product Ecosystem that could include:

  • Minimum Viable Consumable Product
  • Minimum Viable Product Economics
  • Minimum Viable Product Architecture / Design approach
  • Minimum Viable Team
  • Minimum Viable Process

It is not a product …. it is an endeavor, an enterprise, an initiated path to follow, a vision.

… yes, you first need some opportunities in the market, but you can blow up any opportunity without  considering above mentioned aspects.

A product is not …. (just) a product, it is an ecosystem that need to born, adapt and survive.

Adaptive products , , ,

Agile design events and decisions options

Leave a comment Posted by on October 23, 2014

Which are the concerns that should be considered for taking design decisions in an Agile Context?

Let think first about which are the “design events”, the moments in the life-cycle when design decisions are taken. The best description of these events could be found in Agile Modeling method (and inherited in DAD-Disciplined Agile Delivery):

  • Architecture Envisioning
  • Iteration Modeling
  • Look Ahead Modeling – opportunistically “model a bit ahead”
  • Model Storming – just in time modeling
  • … and Coding

TDD and Refactoring are rather ongoing activities, but main design decisions related to them could be also associated  with the any from the above mentioned events.

All the considered design concerns are generic, but some of them are more important in an Agile context (read Adaptive).  This is the proposed list:

  • New versus change: What existent parts will be affected and what is new? Sub-systems, components, external interactions.
  • Clean Architecture: Which are the changes in the business representations and which are the changes in the boundaries with frameworks and drivers.
  • Separation of Concerns: what we need to separate/decouple for Clean Architecture and for TDD?
  • Technical Debt: What Technical Debt we have to manage in the affected existent parts?
  • Cleanup: How much cleanup we need? How much Technical Debt should be payed now?
  • Adapt: What is the need of adapting (design) for affected parts, in the current known requirements context?
  • Adapt design techniques: which techniques should be used and in which amount? Refactoring or Redesign?
  • TDD: the main needed tests and decoupling decisions

Putting all together, we can model an Agile Design Decision Matrix with events and options.

Depending on the moment of the life-cycle, the magnitude of these aspects should be bigger or smaller, but I do not think that any of them should be skipped.

Adapt or not adapt? Cleanup is needed or is not needed? We need or we do not need auto-test?
All are possible options, and any answer it is a design decision.

Important: The answers to these questions will shape the needed work and must be used to estimate time and cost. Each of these events it is a moment of planning and re-planning.

Agile Design:  Simple Clean (& Tested) Design + Adapt

Adaptive Design , , , , ,

← Older posts

Newer posts →

%d bloggers like this: