New product and Minimum Viable Process with DAD

A live ecosystem

With a new product we will initiate and we must keep “alive” a full ecosystem (see previous post “A product … is not a product“) that involve:

• business relationships
• a viable process economics
• sustainable technical solutions
• a product team(s)
• repeatable results
• an evolving consumable solution and others.

What help me and my collaborators in some real cases were Disciplined Agile practices and some complementary ones such Clean Code and Clean Architecture.

“Temptations” and consequences

The first temptations on building new products were we have observed undesired consequences:

• Copy-Paste Process: just repeat – without sufficient adaptions – the process from the existing products (more or less similar with the new one). The pressure could compromise more this process “re-usage”.
• Ad hoc process:  If an existing process is not available, an ad hoc process is adopted without sufficient discipline and many process goals are neglected
• “Normal” life-cycle: direct re-use a “normal” project life cycle, standard for the past projects/products
• Ad hoc team: superficial building of product team, without sufficient collaboration and skills

The consequences could be very unpleasant:

• A fragile product, where the poor design does not allow to reach the opportunities:  cannot deliver required changes, cannot offer a sufficient quality
• The product is not consumable: not enough user level guidance, integration problems, performance problems
• A significant mismatch between offered features and customers’ needs

 Different product – different ecosystem

We cannot re-use the process of a previous product as it is – the elements of the necessary ecosystem could vary more or less, and here are some elements that we found to be different:

• The inherent complexity of business domain or of the solution
• The customers & associated relationships
• Derived from complexity: team skills, minimum viable good design
• Required quality
• Default performance
• Others

As a first conclusion – we need to inspect and investigate the new context and adapt our process in order to build the proper ecosystem. Context investigation and adapting the process must be some permanent concerns, but the expected big deviation introduced by a new product must tell us that this is a special case to be considered.

 Risks, incertitude and opportunities

New product means a higher degree of risks, incertitude, but also possible opportunities. Risks and incertitude must be addressed in order to protect the opportunities and in the same time we need to keep the process adaptive enough to respond to these opportunities.

The main question is what practices and approaches we will need in a such context? We have found some that works.

Incertitude adapted life-cycle

For a new product, it is less likely to have a good enough initial envisioning of the requirements (and of the solution).  The DAD option of exploratory lean startup life-cycle propose a more adaptive approach where initial idea could be repeatedly adjusted after getting business domain feedback about what we incrementally build.

Choosing the right process options

As I have mentioned, the process “deviation” from what we know could be significant. Anyway, the process goals will be similar, but is possible to be needed to choose some different options. DAD main logic was built exactly on this idea. Beyond life-cycle approach we can choose various options for goals such: technical strategy, prioritization stakeholder’s needs, requirements elicitation methods, prove architecture early, validate release.

Some examples of options per goals described by DAD guidance:

• Architectural spikes and/or end-to-end skeleton for proving the architecture early
• Business values, Risks, dependencies as criteria for prioritization stakeholder’s needs
• Coaching, mentoring, training, pair programming for Improving team members skills

When we begin a new product: best time to start adapting our options to the new context.

Effective practices

Building a new product it is difficult endeavor from many points of views: requirements clarification, solution design, (new) knowledge management. Here some key approaches and associated practices that we have found to be successful/helpful.

Effective/Efficient collaboration – apply Non-solo Development for modeling (Model Storming) and programming (Pair Programming). Active Stakeholders Participation.

• Non-Solo Work it is critical for high difficult tasks related with initiating a new product
• Because knowledge is just newly created we need to efficient/effective distribute that knowledge to the other team members and to the stakeholders

Opportunistic envisioning – Look Ahead

• We cannot solve complexity and incertitude only with normal milestone-based forms of looking ahead – Inception Envisioning and Iteration Modeling. It was very useful to opportunistically use Look Ahead Modeling.

Knowledge evolution – Document Continuously, Document Late

• Knowledge is just created – we have suffered when we forgot to capture, at least the essential – Document Continuously help us on this aspect
• From time to time, we have extracted later some overview information (System Metaphor, Architecture Handbook), when our view and results has been stabilized – Document Late

Adaptive process –now is the best time to do that

• The process was rather fluid and was defined/clarified as we advanced and saw what really works in the new context.
• Good options were demonstrated by
• Do Just barely good enough and refine not only your work, but also your process in rolling wave. Use events as architecture envisioning, look ahead modeling, iteration modeling to adapt your process

Minimal good design

When a new product was started, before and after the Minimum Viable Product, we were forced to keep change the product quick and with a sustainable pace. In order to “chase” the opportunities, we had to pay legacy technical debt and avoid as much is possible a new one. A minimal good design, it is necessary to deal with this continuous changes in the case of context complexity.  In this case, Refactoring,  Clean Code, Clean Architecture practices were the backbone for an agile, adaptive design and finally of an adaptive product.

Each distinct product will need a specific Minimal Good Design!

Some conclusions

DAD is built to offer context-adapting guidance. Using Disciplined Agile and outstanding practices as Clean Code and Clean Architecture it was be what we need to build a new product and to define the Minimum Viable Process necessary for that.

DAD and Agile Modeling practices are described here.

Bonus!

It’s not about MVP, but Minimum Desirable Product. via @writebeard #Agile2015 http://www.disciplinedagiledelivery.com/consumablesolutions/

— Scott W. Ambler (@scottwambler) August 5, 2015