This blog post from Borland provides a good example of releasing software frequently to customers.
As Borland develops new features of their products, they permit customers to pick up sprint builds with a caveat:
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.
This is basically alpha releases of the product. This is very pragmatic and makes perfect sense for Borland. Customers are happy they are getting sneak previews and Borland gets early feedback (and some free testing).
Unfortunately Agile Methodists detract from this pragmatism by projecting that their methodologies are in general “fast” and get final results into customers hands quicker than plan driven methodologies. The following commandments of Agile Software emphasis speed, short timelines and fail to mention the crucial caveat (the difference between an alpha release and an enterprise-ready release) that Borland mentions:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
It is this over-statement of claims (and over-simplification of enterprise reality) that weaken the case for Agile methodologies in the real “enterprise” world.
It is also worth noting that Borland does not work with “business” users. Borland’s customers are software developers and they are vastly different from the customers of an enterprise IT shop.
Consider a single mother who wants to know details of her health insurance eligibility for a particular medical condition her child has. Such users are usually not very keen on sneak previews and want the real thing. Software is not the focus of their lives and they do not want to be deeply involved in alpha testing.
Even if the business user is internal to the corporation (a customer service rep who acts as a stand-in for the single mother mentioned above), they are still not very enthusiastic about alpha releases. Their primary problem is they are not paid to test drive alpha release (the customer service rep is paid to take calls from the single mother mentioned above and explain her eligibility to her); they have to do it on extra time.
These are the real-life barriers that limit the efficacy of this release-often prescription. Agile Methodists conveniently ignore these realities when they preach the gospel; I do not have that option!
3 responses so far ↓
Stan Taylor // October 31, 2008 at 7:46 pm |
This is Stan Taylor, the author of the Borland blog post you referenced. Thanks for the feedback!
I’m short on time, so let me point out a couple of things here. You said:
That is actually not the case with Borland’s new suite of products, our Borland Management Suite, which is the product line I’ve been most involved with. These products are geared toward users at various levels of our corporate customers, up to the CIO.
I won’t argue with your claim that our sprint builds are similar to alpha releases. The important difference, though, is that with agile, our customers get alpha releases with small amounts of new functionality every few weeks throughout the release, not just one or two alpha releases that have most of the release functionality complete near the end of the release cycle.
When I get time, I will try to write a longer response on the Borland blog, outlining some of the not-so-obvious advantages of delivering frequent ‘alpha releases’ to customers.
Kishore Kumar // November 1, 2008 at 10:25 am |
I see your point that these releases are much more frequent than traditional alpha releases. But do your customers really pick up every build you make available?
Will look forward to your post on the real advantages to customers of such frequent builds.
Stan Taylor // November 5, 2008 at 12:48 am |
I’ve posted my response on the Borland blog: http://borland.typepad.com/agile_transformation/2008/11/the-first-commandment-continued.html
Unfortunately, my response explores this issue mostly in the realm of theory. I didn’t get to the specific benefits that Borland derives from sharing sprint builds with customers. I’ll post that soon.