When "Agile" becomes "Fragile"

Last week one of my board members, Andrew Nash, shared a conversation with the CTO of one of the ten biggest software companies in the world. The subject of the conversation was agile development. The CTO complained to Andrew that agile development is worthless if you cannot extend the stream of innovation to customers in a timely manner. What does it matter if the application developers deliver code to release engineering and QA on a monthly basis if the subsequent delivery and consumption by the customer takes between 6 months and a year? The valuable concepts of rapid feedback and minimal work in process get blown away because navigating the matrix of pain and distributing innovation to customers is so inefficient. If application providers are to truly gain benefit from agile development, they are going to be forced to embrace appliances, virtual appliances, or SaaS as the delivery model. Without control over the the system software as part of the application delivery and consumption cycle, agile development rapidly deteriorates to fragile development and becomes worthless.

Agile development is a close cousin to the lean manufacturing concepts pioneered by Toyota in the mid-80's and early 90's. The concept is simple – keep work in process to a minimum in order to discover and improve mistakes with a minimal amount of waste and rework. Agile development likewise seeks to keep work in process to a minimum in order to avoid large scale mistakes in architecture and feature design by facilitating rapid feedback throughout the value chain – from the developer, to QA and release, and ultimately to the customer. It has the side benefit that products that rapidly evolve to deliver ever greater value to the customer become “stickier” and less prone to competitive displacement. It often happens that a competitor replaces a product because the upgrade to new features in the incumbent product was more expensive than the switching costs to the competitive product. Just ask the folks that used to work at Baan about this problem. SAP made a killing switching out Baan customers due to extraordinary upgrade costs.

In order to prevent software “work in process” from piling up at the proverbial shipping dock (i.e. release engineering), the complexity of the release engineering matrix must be dramatically simplified. Fortunately, appliances, virtual appliances, and SaaS all provide this goal of simplification, and they are rapidly becoming the de facto delivery model for much of the new software being consumed in the market today. These improved distribution models enable application providers to do something good for their customers and their developers in one fell swoop. Customers get more innovation with fewer hassles, and developers get to work on new features instead of grinding away to solve the problems created by the context of release engineering. If you hope to embrace agile development and avoid fragile development, you better sort out your distribution strategy as well. The legacy approach will not get the job done.