A common question is how to strike the right balance between the preservation of the flexibility of Agile software development with customers’ legitimate desires to have delivery commitments. At Demandware, I often thought this tension was somewhat unique to us, having adopted Agile and striving to increase the frequency of release upgrades to our customers (from two per year to over ten per year). Now I recognize that all enterprise SaaS businesses struggle with the same issue.
I am not discussing deliveries of new products, but delivery of features that are released to all customers as enhancements to their capabilities. For companies that have adopted some variety of an Agile, with relatively short sprints followed by deliveries, the ideal approach is to be working on the highest priority features and delivering whatever is complete with each sprint. Rather than committing what is planned for future sprints, the philosophy is that this approach will result in higher levels of throughput with consistent quality and higher responsiveness to the market. Research into software development confirms that this is true.
Nevertheless, from a customer perspective, this is not a very satisfactory approach. Customers have to make plans for their own businesses and those plans can be significantly affected by features that are delivered (or not delivered). For instance, a customer might have to hire more people as they grow to deal with an inefficient business process. If, however, a particular feature is delivered, the hiring could be avoided and the business process streamlined. The budgetary implications of such a difference need to be planned by the customer. Or, alternatively, the customer might need to deploy IT resource to build a customization to work around an absent feature. Their IT organization often requires significant advance planning for the business to get the resources necessary. For these reasons and others, from a customer’s perspective, the ideal would be reliable vendor commitments to feature deliveries for a year in advance.
So, how do you resolve the tension between these? First, recognize that there is no solution which perfectly matches both ideals. Then start with an understanding of the features that most significantly affect customer plans. This set of features will most likely represent a minority of the engineering work likely to occur. (If not, the words “most significantly” in the previous sentence have not been properly applied.) The goal is to make date commitments for those features without committing so much of engineering that the benefits of responsiveness are lost or that delivery pressure (when the unexpected occurs in software development) results in quality compromises. Committing 25% of the expected engineering capacity (above and beyond that planned for bug fixing) to deliverables is reasonable. This could be pushed a bit higher but if it exceeds 50%, it has certainly gone too high.
Then the question becomes what date to commit. It is important not to commit to delivery in a specific release (assuming you are doing releases relatively frequently, such as at least one per month). Doing so results (when the unexpected occurs) in having to choose between violating the commitment, delaying the release, or compromising the quality. Nothing about SaaS or Agile has changed the fundamental reality of software development. There are three dimensions (time, scope, and cost), and it is exceedingly difficult to guarantee that all three are achieved exactly as predicted. Ideally, adding cost might often appear to be the best choice when they don’t. However, adding cost by hiring more engineers will usually not speed up the project in the short to medium term (and will often slow it down). Sometimes cost can be added by redeploying engineers from another feature (this is why it is so important not to commit too large a percentage of engineering capacity). But often this won’t help either. Then the tradeoff becomes between time and scope. The beauty of Agile is that it holds time constant for each sprint and allows the scope to be fulfilled from highest priority to lowest across the features. When scope becomes relatively inflexible (due to a customer date commitment on which customer planning was based), time is the only variable remaining. For this reason, the date commitments should allow some room for the unexpected.
For example, if you are in January and engineering believes the feature in question is likely to be complete for the June release, it would be prudent to commit Q3 as a date commitment to the customer. In the event the feature proves unexpectedly complex, cost can be added (to the extent this helps) or the time for delivery can be expanded to include three additional releases (July, August, and September) without violating the customer commitment.
The approach outlined here is certainly not the only one but I do strongly believe that for an enterprise SaaS business, being at either extreme (i.e. committing no future deliverables or full transparency into all delivery expectations for the future) is detrimental to the long term health of the business. As the philosopher Yogi Berra famously remarked “it’s tough to make predictions, especially about the future”.
