Thou shalt deliver software early and continuously

The author of the UML tutorial blog has declared that agile is 'the new religion' and that the principles behind the agile manifesto are really The Twelve Commandments of Agile. The blog's author states that he does not necessarily disagree with the principles but believes that agilists treat them as religious dogma. Unfortunately, I think the blog's author is the one who is mistaking principles for dogma.

The first commandment he comments on is the agile principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The blog's author comments:

Next let us considered if it is practical to make "continuous delivery" to a production environment? Anyone even remotely familiar with enterprise application rollouts will tell you that a production release is a big deal. No company can afford to approach a production release in a cavalier fashion and no IT department of a Fortune 500 company every will. A release every quarter is the highest frequency they will countenance. If I tell them I will make "continuous" releases, well, my consulting days with them will come to a premature end!

As someone who's involved in ensuring the enterprise readiness of Borland's software, this is a topic that's near and dear to me.  Borland's process is: we give our software to customers each sprint for acceptance testing only, which allows our customers to try out the completed functionality and give us feedback quickly. However, we deliver enterprise-ready releases a only few times a year.

When a customer takes a sprint build of our software, they agree to the following condition: the delivered functionality should be functionally complete, but the software has not yet been subjected to full enterprise testing, and it is therefore not ready for and should not be deployed to production systems.

You may infer from the paragraph above that we don't do enterprise testing in an agile fashion--we save it until the end of a release. That's not accurate. Typically, we perform enterprise testing (at most) one sprint behind the sprint in which functionality is delivered. Then at the end of the release, we have a 'release readiness' sprint in which no new functionality is delivered. One purpose of this sprint is to allow the remaining enterprise testing to be completed.

In this way, we feel we uphold the spirit of this agile principle--deliver frequent, incremental progress--in a way that works for the enterprise software that we develop.

Comments

[Ian Buchanan]

The author's statement about enterprise production environments is a bit overstated. Namely, there are many large tech and telecommunications companies in the Fortune 500 who have been very successful at frequent updates of production systems, sometimes updating them as often as multiple times a day. Of course, these updates are not "cavilier". The disciplines of automated testing and continuous integration help insure the impacts are well known before the change is made.

But, Stan, you are also right to point out that continuous delivery can mean different things for different people. Delivery may not mean full deployment.

[S. Kishore Kumar]

Thanks for a concrete example of a Agile methodology in practice. A quick study of you example helps position Agile methodologies better:

Borland products are "by developers for developers". It's your customers who produce software "by developers for business". Hence you are one removed from business users. (Your customers' experiences with Agile would be more relevant to my context!)

Given this characterization, it is possible for you to make alpha release and still "satisfy customers" (i.e. they feel happy they are getting a sneak preview).

In the case of software "by developers for business", alpha releases do not garner too many credits. Business users are tough cookies. If I claim to make bi-monthly releases they have to be production releases and not alpha. This is where the claims of Agile Methodists fall short of reality for me. I cannot "satisfy customers" with bi-monthly alpha releases.

I myself have made "feeler" releases to business during latter stages of a waterfall (or at the end of 3-4 month iterations). And received valuable feedback. But I don't do this every two weeks! They just don't have time to look at it. Remember, they have a business to attend to!

If this Commandment were modified to read "Our highest priority is to solicit customer feedback through early and continuous delivery of valuable software." then it becomes somewhat more realistic.

It is phrase "satisfy customers" that rings hollow. With alpha releases you are not satisfying customers; you are only covering all your bases.

[Stan Taylor]

Kishore,

Thanks for commenting here. Before I saw your comment here, I posted a comment to your blog. Incidentally, my comment addresses your characterization of Borland's software as 'by developers for developers.' Please see my comment on your blog post for the details: http://advanceduml.wordpress.com/2008/10/30/frequent-releases-of-valuable-software/#comment-66

I'll post a longer reply here in a future blog post.