Tag Archives: Agile Products

Reactive & Adaptive Products: built-in feedback

Reactive Manifesto

The Reactive Manifesto, initiated by Jonas Bonér, want to respond to the new context with “with multicore and cloud computing architectures […] with tighter SLAs in terms of lower latency, higher throughput, availability and close to linear scalability”

See more at: https://typesafe.com/blog/why_do_we_need_a_reactive_manifesto%3F#sthash.gP9WznCO.dpuf

Some default (software) systems requirements should be in such case these ones (quote, from below mentioned source):

  • react to events: the event-driven nature enables the following qualities
  • react to load: focus on scalability rather than single-user performance
  • react to failure: build resilient systems with the ability to recover at all levels
  • react to users: combine the above traits for an interactive user experience

See more at: https://typesafe.com/blog/why_do_we_need_a_reactive_manifesto%3F#sthash.gP9WznCO.dpuf


Requirements to be reactive

Well, that sound very interesting, but when it is transformed in the Manifesto (http://www.reactivemanifesto.org/), the resulted thing is a combination of requirements and solutions, because “message-driven”, async messages it is a solution, for example. My personal taste is to keep first the requirements, that seems to be more generic:

  • react to events, react to load, react to failure, react to users



I have some start questions

  • Before production: how could I know that I will build a system that will “enough reactive”, that will react enough to the load?
  • During production: how could I know that the real loading it is not bigger than estimated loading, for example, and what are the exact numbers in case of incidents?


 Traditional answers and beyond

The “traditional answer” is : “ok…we will do the needed performance tests“. Right! What about second type of questions, real loading and incident (or needed) analysis ? The next answer is that we will need also data gathering tools  built-in in the product, not (only) in offline tests.


 Adaptive products: built-in feedback

If we need to follow REACT types of requirement or similar, in an adaptive context (read Agile), we need to follow the principles of Adaptive Products and make sure that will not miss the link related to the early and continuous feedback from business/production back to the products. In such cases, the product itself should have the above mentioned data gathering tools  built-in in the product, not (only) in offline tests  (with a possible smarter option of self assessment).


Consumable Solutions: Measurable!

Reactive and similar properties of the software systems cannot be claimed if are not measurable in production and in tests. Using this feedback, the system could be configured or adapted by adequate changes.  Such capabilities of the products must be part of of the criteria for consumable solutions (concept used and introduced by DAD – Disciplined Agile Delivery). If the real capability of the system is not known, if there are incidents and if the needed information to adjust according to the needs  it is not available just-in-time, then it is not a consumable solution.

Some simple examples:

  • Events most be registered with occurring timestamp , start and end processing timestamps,  type of response
  • Details sub-processing data must be gathered if are significant
  • Number of events/processings should be registered if are bigger then and estimated threshold
  • System internal availability of various resources should be available for monitoring
  • More info should be “dumped” on incidents and fails


Update – Critical versus Important

(After a discussion thread with Martin Thompson on Reactive Systems Google group)

There are 2 kind of cases:

  • Systems where REACT capability is critical (such some financial systems) – the “elite
  • Systems where REACT capability it is important, but not critical – the “majority

The critical cases (the “elite“) need a complex approach with external and internal measurements, with specific care for high amount of non-linear data/events and accuracy of measurements in such context. In many cases, these are domains with specific regulation that request a mature approach for measurement.

The “majority” instead have rather an insufficient support for measurement. Also, in such cases, the cost of measurements could be important.  The best approach should consider smart, opportunistic  solutions, that will maximize the return of investment with less effort.  The built-in support for feedback could offer such solutions because have access to the “intimate knowledge” of the system, that mean most effective/efficient measurements..

The lesson is: Even if you know exactly what is going on in your system, measure performance, don’t speculate. You’ll learn something, and nine times out of ten, it won’t be that you were right!” – Ron Jeffries – “It Takes Awhile to Create Nothing” (from <Refactoring: Improving the Design of Existing Code>)

Agile product = Adaptive product

Product problems compromise value delivery

Agile most marketable and viral aspect it is “value delivery”. That sounds great, but that will not solve all the problems of the software development and also it is just a one-dimensional representation of Agile.

The biggest remaining problem for Agile development are the product problems.  Often delivery and small releases will address some well known problems in software development that too often will cause project failures. Small releases, working software and close customer collaboration will reduce the project level complexity, one of the major reasons for these failures. 
What about product problems? Generic problems are related with accumulation of technical debt, brittle architectures and loss of intellectual control over the product knowledge. We need a solution also for that aspect.

Technical Excellence

 A great response to such problems it is introduced by Agile Manifesto by demanding “technical excellence” and good design. Jeff Sutherland says that as a conclusion after 10 year of the Agile Manifesto, “technical excellence” it is a key factor of success of Agile teams.
The question is if these two principles to follow – close to the customer and technical excellence – are sufficient to cover all kinds’ of possible problems.

Others problems

A tough real-life scenario is related to new products or new significant part of the product that need to be distributed, deployed to more clients. An initial one-time distribution to more clients it is rather Waterfall than Agile despite the fact that developing could use iterations and customer collaboration. There are several reasons for that: a full-new product deployment it is equivalent with a big release (also with a rare delivery) and it is hard to imagine that we will work close with all the customers.  
A great Agile solution for such kind of problem suppose, an (obviously!) incremental approach. Scott W. Ambler has described such solution here (“An Exploratory “Lean Startup” Lifecycle”):
 This problem and the product knowledge problem need supplementary solutions.

Solution step #1 – Inject the business

The main conclusion is that we have a supplementary dimension of Agility beyond often delivery: we need to often and continuously inject back the business into the product. The product should be kept close to the business where will be integrated.   

Solution step #2 – Products with “Business DNA”

Other question:  how we could know that that business “injection” will be effective, when some recurrent problems are the loss of the intellectual control over the product knowledge and the product fragility because of increasing technical debt. Let remember what will request Robert C. Martin if will be your CTO (): “We will not ship shit.“, “You will always be Ready.”, “Inexpensive Adaptability.
We will always be ready with inexpensive adaptability if will be performed a creative work to model that business before include it in the product.
The deliver product or product change will need to “live” inside the customer business and will need to adapt and evolve in that environment. 
In order to realize a „natural” evolution inside the target business, the software system must have „Business DNA”. Translating that in engineering measures that mean all architectural aspects must serve that business integration.

Solution step #3 – Implementing the “Business DNA”

There are some software engineering instruments that could build and protect the „Business DNA” for a software product.
Functional cohesion
  • The core structure of the software should match the real business functions. A change in the business will be reflected with minimum effort and with maximum quality in these cases
  • That will be the core representation of Business DNA
Separation of concerns
  • Beyond any particular architectural or design patterns, a basic rule is to kept distinct concerns decoupled. A default separation should be the one between technological aspects and functional aspects
  • That will protect the Business DNA from technological changes
Good design & technical excellence
  • Good design will enhance any software development enterprise  

Solution step #4 – Agile product = Adaptive product

The missing link in Agile Development seems to be a principle that requires an “Adaptive Product”, with good design and “business DNA”. We should always think to “Agile Products” as “Adaptive Products”.

Agile Products – an Agile "Missing Link"

Agile Manifesto: “Customer collaborations”, “Early and continuous delivery”, “Deliver working software frequently”, “Business people and developers must work together daily“.
Extreme programming: “Make frequent small releases.”,  “This is critical to getting valuable feedback in time to have an impact on the system’s development. The longer you wait to introduce an important feature to the system’s users the less time you will have to fix it”.
Scrum: Maximizing value delivery.
Yes,  all the Agile logic it is about serving the customer business by delivering value, early and often and by a close collaboration. That sounds great, but it is only one viewpoint.

Our software should be developed in above mentioned manner and then that product must be able to follow the customer business ~  our products must be in proper shape for a such endeavor.

It is that simple?


In each moment of time, the product need to be easy and quickly adapted to some new requests that corespondent do some new business needs.

It is that simple? Usually it is not.

First release problems – The product it is new and need to be deployed to more customers – there it is a big probability that many product features to not match to the business and we need to continuously add other features.

Mature product problems –
The product it is “old” by accumulating a lot of technical debt and the respond to the changes become slow.
We need to take care about customer business, but that supposed to take care also about the product !


  • Development to Business – DELIVER VALUE to the customer
  • Business to Development – INJECT BUSINESS into the product 

“Delivering value”,  “Delivering value”,  “Delivering value” … in fact there is more than that. The delivered product will “live” in the customer business process and need to be able to evolve and adapt with that business. The BUSINESS DNA must be injected into the product, in order to accomplish such goals.

Here some useful principles:

Adapt the product to the business

  • with early, continuous and frequently delivery of valuable software.
  • with  close customer collaboration, “business people and developers must work together daily throughout the project.”
  • with “small releases” (~XP), because any big release will lose contact with the business
  • with  “constant pace indefinitely“, that suppose low level of Technical Debt
  • with a good visibility and work optimization via a a well refined Product Roadmap

Keep this business clean: easy to read and change inside the product

  • Well crafted software“, “technical excellence and good design” – that enhance adaptability
  • Steadily adding value”
  • Test-driven development – the business value is constantly and often checked and demonstrated
    •  TDD sustain refactoring and refactoring sustain adaptability
  • Clean Code ~ less Technical Debt
  • Clean Architecture – decouple the business concerns

(Quotes, principles and practices from: Agile Manifesto, XP, Scrum, and  Software Craftsmanship Manifesto)

There are two different Agile promises

  • “we can serve your business now“- you may sometimes succeed without craftsmanship
  • “we can serve your business now and indefinitely” – that need all the engineering parts that suppose “steadily adding value” , technical excellence and management of the Technical Debt.

The product level concerns: injecting the business into the product and keeping that business clean are mandatory for that second and stronger promise.

%d bloggers like this: