Tag Archives: Adaptive Design

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!

Before DevOps: Delivering more by delivering less

Undesired complexity give undesired deliveries

There are many aspects to consider related to DevOps and delivery, many strategies and (in the right context and the right approach) there are also some very useful tools. It is a complex issue and last thing that we want is to make that even harder because of undesired complexity. A poor and an un-appropriate design is the main cause of the problems.

Suppose that the main aspects of a product functionalities and design are the followings:

  • Functionalities: f1, f2, f3
  • Business rules: r1, r2
  • External frameworks, technologies, and drivers (APIs, hardware interfaces, others) e1, e2
  • External interfaces: i1, i2,
  • Technical mechanisms: t1, t2, t3..

Should stay together only what it changes and should be deliver together.

As generic rule, if one of this aspects it is changed, we do not want to affect, change and deliver others aspects. Below are some examples of anti-patterns.

Anti-pattern: Lack of functional cohesion

Just a start example: If was requested to deliver a change for the functionality f1, it is highly undesired to change also functionalities f3 and f4 only because f1, f3 and f4 are unnecessary coupled in the implementation. This coupling could mean: same function, same class or same package as opposite of using distinct design elements.

Anti-pattern: Non-DRY business rules

If the business rule r1 it is used in more functionalities (that have dedicated components) and that rule implementation is duplicated (multiplied) in every functionality, then a change in r1 will require change and delivery for all those functionalities and components.

Anti-pattern: Mixing functionalities with external communication

Suppose that f1 and f2 are using TCP sockets for communication with some external systems and we need to replace this type of communication, if the f1, f2 implementation is mixed with socket management aspects, then we need to change and deliver also f1 and f2.

Anti-pattern: Mixing functionalities with external interfaces

External interfaces could suppose handling of some specific external data structures and/or of some specific communication protocol. If we are mixing these parts with internal functionalities, with any change in the interface, we should change and deliver also some not related internal parts, .

Anti-pattern: Mixing functionalities with technical aspects

You need to protect the representation of the business inside the product from the changes related to technology. Where is the technology involved? Any I/O aspect that wrap the hardware: GUI, network, databases, file systems is strongly related to technologies and platforms. If, for example, you have a lot of functionality and business representation in the design of the GUI elements, any change in GUI technologies will affect the business representation inside the product, that should also massively changed and then delivered.

Anti-pattern: “Utils”

A symptom of a poor design that could cause undesired supplementary work on development and delivery are the “utils” packages, especially without clearly dedicated sub-packages. Examples:

  • “utils” package that mix together classes belong to different functional aspects
  • “utils” package that mix various technical aspects without having dedicated sub-packages

This kind of design suppose that we need to change, test and deliver the “utils” almost with any change of the product.

Anti-pattern: Dirty code

Breaking simplest Clean Code rules (similar with the ones that are used in refactoring) could cause undesired coupling and undesired increase of delivery scope. Some examples that could induce such problems:

  • Any duplicate/multiplied code
  • Breaking SRP principle
  • Global context data, global variables (breaking Law of Demeter)

Minimizing the need of change and delivery

We need to reduce the need of change and delivery only to the required ones. There are several practices and approaches that could avoid that problem (the examples presented above or similar ones):

  • Keep the code clean by writhing Clean Code first and refactor and pay the technical debt whenever it is necessary
  • Use functional cohesion as the main criteria of creating components and packages
  • Use Clean Architecture that propose a default, strategic separation of concerns
  • Extend XP engineering practices (Simple Design, Refactoring, TDD) with the ones from Agile Modeling and DAD
  • Respect Law of Demeter on any level of the design – do not use any global context
  • Make the products adaptive by keeping up-to-date with target business by often and early injection of feedback from that business.

You can argue that I already write about all these in a previous post “Roadmap to an Agile Design”. Yes, indeed, in order to deliver just what it is needed and avoid waste you must have an Adaptive Design, the main characteristic of an Agile Design.

In order to that you should be open  to all outstanding agile practices for design and do not be closed in the smaller universe of some very lightweight Agile methods. And remember that those lightweight methods are not created as full process methodologies, but as indications to build a customized process.

Imagine that all these problems are far worse if we have multiple variations and variants of the same product. The massive effort for any change and delivery will block the overall agility and responsiveness of the development team and massively reduce the overall economics for both development and customer side.

Use a strategic separation of concerns

Do not use any reference to any global context

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

JIT – Just in time and Software Development

(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
%d bloggers like this: