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.

Technical Debt Patterns

(More details – article Know and Manage the Technical Debt, Software Development Journal)

Prevention_Versus_Correction 

• We should focus continuously on quality by adopting “built-in” quality versus “inspected-in” quality. In fact, the “test&fix” approach will give a temporary quality and will hide the debt. Finally, it is pretty naive to address quality only by test & fix.

Levels_of_Design_Versus_Debt 

• Because TD is related to software design, it is also related to the Levels_of_Design, where each level could introduce – more or less – its own part of technical debt. Here are some levels (others could also be taken into consideration):

• Coding style
• Clean code rules
• Design decisions in context
• Architecture decisions

No_trade_for_basic_levels 

• “Bad code is always imprudent.” says Robert C. Martin 

 Methodology_Induced_Debt 

• Use context-adapted iterative approach, that mean the right design strategy in the context.
• Agile techniques: Clean Code (“prefactoring”), Refactoring, TDD (pay the debt early)
• Risks-driven techniques: Architecture-driven approach.

 Avoid_Mega_Debts 

• The cost of a such debt could be exponentially higher then of the normal debt. Examples:
• Refactoring nightmare by Interfering_Debts (such unsearchable names + “duplicate” code); 
• Envious_Monster – mega components that present “”feature envy” for many other components;
• Big_Design_Elements 

 Register_the_debt 

• In order to manage and pay the debt , you should know and register the debt

Manage_Mega_Debts_First 

• Big, important and messy – that is an explosive problem.

Define_and_Use_Thresholds 

• Beyond applying metrics, should be associated some risks thresholds to some significant metrics.

Search_Usual_Suspects 

•  Feature envy, big size, no separation of concerns; searching for them could offer a quick assessment and a quick reaction

Use_Separation_Of_Concerns

• That is the design principle with biggest impact on debt management.

Long_Term_Steadiness

•  See Software Craftsmanship Manifesto

Honest_development

• Clearly define the responsibility of managing the TD