Monthly Archives: May 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 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 !

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 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: