You Want IT When?

Agile doesn’t work in the real world is essentially the conclusion of David Starr, an Agile proponent, in his article “Why Agile Doesn’t Work.”  First, he informs us of what is the primary objective of Agile software development methodologies:

Sure, TDD works, so does continuous integration, and a host of other great development practices. The truth is, though, that the real Agile value proposition was never about code. Better software with higher quality and excellent craftsmanship is a great side effect, but Agile is really about changing how products are created and delivered. Agile intends to fundamentally change the model of your relationships with clients and coworkers.

David Starr then proceeds to explain, “Agile supports the idea of frequent delivery of value to customers.”  This is essentially where Agile hits against reality as he further supports in the article.  He identifies two primary reasons why a frequent delivery to customers is problematic in the real world of business. 

1. Once the software exits development, your company’s operations takes too long to move the software to customers.
2. Customers are unable to deploy new versions of software to their users quickly.

His reasons in support of these two points are logical and real.  Read the article; it’s very good.  I make a similar point in my essay “Danger: Agile Practices at Work,” where I also suggest that the goal of frequent delivery of software to most customers is unnecessary.   However, where I disagree is when he suggests that the way to fix this is to have Agile business operations. 

While solving the problem of moving software to the customer faster may help companies that build software, it doesn’t make much sense for most customers to continually have frequent releases of software.  This is true for both companies using software for solutions in their own products, and it’s true for customers that simply use software to run their businesses.

Customer perspective running a business

A successful software product usually solves the primary problems for a majority of customers within the first release or two or maybe three.  For example, let’s examine Microsoft Office suite of applications.   I’ve been using the Microsoft Office suite of applications since the early 90’s when they first became available on Windows.   I basically use the application in the same way as I did with my first purchase around 15 years ago.  I’m not a power user, and I don’t need to be one.  I regularly use 20% or less of the features, and they more than satisfy my need.

Let’s examine another application that I regularly use at home.  I’ve been a Quicken user since the late 80’s when I first purchased it for the Apple Macintosh.   It’s a great application for people who like to keep their checkbooks in balance and manage their stock portfolio.  For the primary consumer purpose of managing financial transactions, Quicken really hasn’t changed much in nearly 20 years nor is change required.

Yes, there have been some improvements along the way that have been valuable in both applications, but most of the time, even with the newest versions, I use the applications as I did when I first purchased them.  For users of these wonderful applications, their objective is to use these applications to solve problems, and if the current version is solving their problems, there really is little reason to purchase the newest version even if it provides more value.  After all, if the current version isn’t solving their problems, then why are they using them?

The only new feature in Microsoft Word that would compel me to purchase the newest version right now is a feature to significantly improve my writing.  For Quicken, there are two features that would compel me to upgrade: one feature is to improve the investment research capabilities.  The other feature is to completely remove the manual entry of downloaded transactions. 

However, even with those features added, price is a factor.  Business and consumers aren’t in business to keep software companies profitable.  They’re not going to purchase every new release even if the value is compelling enough.  Purchasing decisions are always a tradeoff amongst other needs.   Sometimes the reason is only money, other times it’s business priorities, and still other times, the current version simply works good enough for the customer’s needs.

Are the reasons different for software shops?

In my experience never has a naked third party component provided business value to my customers.  If it did, there would be little reason for my development team to exist.   If you’re building a software product, your company has identified an opportunity to add value that either doesn’t exist or value beyond anything out there in the marketplace today.  Third party components add the least value in comparison to the value delivered by your application, so there’s little motivation to upgrade third party components.

When I was writing Windows code for the financial industry throughout the 90’s, very little of our application code was interfacing with the third party components or operating system.   While third party components are important and often necessary, upgrading to the next version of our third party components took time and effort away from delivering additional value to our customers.

It is often rightly a struggle with product marketing to support third party component upgrades in the next release.   Customers don’t purchase applications because they work on the latest version of Oracle or some other third party application that may be part of your product.  Third party components are very often transparent to customers.  They rarely care about what parts are used to assembly your product.    Unless the latest release of the third party component provides some value to the end user of your application, time is better spent investing in customer requirements identified by your product marketing team.

Summary

I suppose David Starr is correct when he says, “Agile is really about changing how products are created and delivered.”  Though, I’m often unsure of what Agile is really about as I often read conflicting opinions from other Agile proponents.   If Agile is “about changing how products are created and delivered,” it’s not a requirement for most customers.

In my product development experience, the next release is mostly about satisfying the following needs:

1. The next release is mostly to expand market share.   It’s about building the new features that will expand the addressable market.  That’s one reason why most users regularly use a small percentage of the delivered functionality in any application.
2. The next release is to support marketing.  It’s about having an answer to your competitor’s features, so when the salesperson pitches the product to a new or old customer, it compares more favorably than your competitor’s product.
3. The next release is to maintain market share.   It’s about giving your customers no reason to evaluate your competitor’s product or even decide to purchase it.
4. The next release is to give your existing customer base a reason to upgrade. It’s about building the features that have additional value for your customers.  However, for the reasons explained above, most of these customers don’t have a need to upgrade as rapidly as is commonly accepted by the Agile community.

David Starr argues that Agile doesn’t work because business operations aren’t Agile, and his remedy is to have Agile business practices that embrace change:  “Embrace continuous integration of the enterprise.”     Customers don’t want continuous change; they want a great product the first time they purchase it, so they can spend more time serving their customers and invest more money on other important needs.  While your product delivery is most important to you and your company, it’s likely not the most important need for your customer.  Agile simply solves the wrong problem.

If you liked this essay, you may also like the following related posts.

• Quality Matters More
• Agile Content is the Goal