Agile "Missing Link": Adaptive product - Scenarios when you are not Agile

Does not matter the adopted practices, and the Agile claiming:  a team will be Agile only if will be able to respect the Agile values and principles in a steady manner, by serving the customer business also on medium and long term. That suppose also having Adaptive Products (see previous post).

Here some scenarios when the product is not adaptive, and that will not qualify that team for real Agile development.

Big Bang Delivery of new product

Similar with that cosmic (hypothetical) phenomenon, you could try to deploy to the market to more customers a completely new product (or a significant part) where the functional and non-functional attributes (performance, usability and others) are not yet subject of a real business feedback (from production usage). 

Does not matter if you have Small Iterations, Product Backlog, Self-Organization, or Technical Excellence, because are missing Often Delivery and Close Customer Collaboration. Usually, when you are building a new product will collaborate rather with one customer, that mean you are really close only to that customer. Also there is high probability that both functional and non-functional product proprieties will not fit too well for the rest of the customers.

There is the custom to have a "pilot" deployment, but that it is not enough, because, after the pilot should not be adopted the Big Bang delivery, but, also in this case, an incremental approach. 

See Scott W. Ambler solution "An Exploratory “Lean Startup” Lifecycle"
https://disciplinedagiledelivery.wordpress.com/2014/04/25/an-exploratory-lean-startup-lifecycle/

Long projects - Big Releases

 

It is a similar context with the "Big Bang" delivery to multiple customers. The Work In Progress will be too long, your result will get too late a real business feedback. Many feature could not match with real business needs or could become deprecated.

Anyway, big releases are not Agile also because the Agile solution for complexity of the software projects are the Small Releases. 

Spaghetti Code, Big Technical Debt 

 

Poor design , Spaghetti Code, accumulated Technical debt will reduce the product adaptability, the reaction to changes, the overall quality (the list of damages remain open). Such products are definitely destroy the agility.

Just a good design ...

 

"Continuous attention to technical excellence and good design enhances agility. "  that is a great principles from Agile Manifesto.

Well ... That is not enough, from technical point of view, to sustain the Agility!

A real agile product must be an ADAPTIVE PRODUCT, where the business is well modeled, it is decoupled from the technological aspects. The business representation inside the product should have the following properties for supporting Agility:

• must survive with smaller costs, quick adaptation and no quality problems to the technological changes
• must support also quick adaptation, with smaller cost and no quality problems to the business changes

Two design principles will give the biggest help to realize these capabilities

• Separation of concerns - especially to decouple technological aspects from business aspects. Also could be applied to decouple different technological parts from one of other , or business aspects
• Functional cohesion - should be the main instrument in injecting the business DNA into the product, where the software system design should match its functions 

An agile product must have a "Business DNA" , realized by functional cohesion and protected by separation of concerns and a good design.

My witness :-)

Well, if you do not believe me, maybe you trust in Robert C. Martin.  His design principles are a great "testimony" in favor of Separation of Concerns (Single Responsibility, Dependency Injection). I recommend also these presentations, that promote Functional Cohesion as main attribute of a good architecture.

Clean Architecture and Design-2012 COHAA The Path to Agility Conference

https://www.youtube.com/watch?v=asLUTiJJqdE

Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin

https://www.youtube.com/watch?v=WpkDN78P884

Agile "Missing Link" (2): 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”):

http://disciplinedagiledelivery.wordpress.com/2014/04/25/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 ... The product must be able to follow the customer business...But that mean should be in proper shape for a such endeavor. It is that simple? I think it is a little more complicated.

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?

When time = zero. 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.

When time = several years. The product it is "old" by accumulating a lot of technical debt and the respond to the changes become slow.

We need to care about customer business, but in the same time we need to care about the product! 

There is a TWO WAY ROAD TO AGILE :

• 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 the same pace 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 busines
• with  "constant pace indefinitely", that suppose low level of Technical Debt
• with a good visibility and work optimization via a a well refined Product Backlog

- 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 and less Technical Debt
• System Architecture that serve the business concerns

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

There are two different Agile promises
- "We are Agile and currently we can serve your business" - management practices from Agile can support a such promise - such many of the Scrum Practices
- "We are Agile and 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: inject the business and keep that business clean are mandatory for that second and stronger promise.