Wednesday, May 14, 2014

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.