The Agile Executive

A Continuum

The traditional way of examining software from a life-cycle perspective is phase-by-phase. The software is developed; deployed; monitored; maintained; changed; and, eventually retired.

True though this description is, more and more executives these days actually view it all as one continuum. An application is developed, and  then deployed and maintained as part of some business process. At a certain level it might not really matter to a business executive what the software life-cycle is and which party carries out what phase. The thing that matters is that some service is performed to customer satisfaction. One could actually do complete  Business Process Outsourcing, chartering  a third party to take care of all the “headaches” in the continuum – from coding a critical software component to repairing a delivery truck to answering calls like, “My shipment has not arrived on the promised date.”

This post looks inside the continuum to comments on the implications of increasing the number of releases. Aspects related to, IT operations, IT service management and the customer as a strategic partner will be discussed in subsequent posts.

Number of Active Releases

The delivery of value to the customer is a fundamental tenet of Agile. The whole Agile development process is geared to that end. Customer value, however,  is realized when the customer is able to start using the product . As deployment cycles for enterprise software can be quite long, time gained through Agile development is not necessarily of immediate value to the customer. For customer value to materialize, the deployment cycle needs to be fast as well.

Companies that use Agile successfully can be quite different with respect to deployment practices. Here is a quick comparison of BMC Software, PatientKeeper and Google:

• The successful implementation of Scrum at BMC Software led to producing 3-4 releases of the BMC Performance Manager per year.  However, time to deployment by various customers varied greatly.  Hence, a relatively small number of releases was active at any point in time.
• With PatientKeeper,  Sutherland exploited the hyper-productivity of his Agile teams to produce a relatively large number of releases. When a customer needed a “release” it was downloaded via VPN and installed in fairly short order. Some 45 active releases of the software existed at any point in time.
• Companies such as Google expedite deployment by using Software as a Service (SaaS) as the delivery mechanism. Google has only one actively deployed release at a time, but produces many fast releases.

As one increases the number of releases, a reasonable balance between velocity of development versus velocity of deployment in the continuum must be struck. To streamline end-to-end operations, velocity gains in one should be matched by gains in the other.

It does not Really Matter if you can Tell the Egg from the Chicken

One can speculate on how things evolve between development and deployment. Whether Agile software development leads to improvement in deployment, or Software as a Service “deployment” induces faster development processes. The Agile philosophy is well expressed in either case. In either direction, the slowere speed area is considered an opportunity, not a barrier. A Software as a Service Operations person who pushes for faster development speed lives the Agile philosophy even if he knows nothing about Agile methods.