Why do organizations decide to try agile software development? The simple response is that they want to improve their software development results. Sure, but what exactly are they trying to “improve“? Here are the most common improvement candidates:
- Time to market – they want to generate software releases in less time from start to finish.
- Better quality – they want to reduce the number of customer complaints (defects, usability problems, performance, etc.)
- Lower cost – they want to reduce the cost of developing and supporting their software
Can agile development deliver all of these benefits? Not likely. It can help but it’s not a panacea. If agile development doesn’t guarantee top and bottom line benefits, what business value does it offer?
Consistency and Predictability
Every business wants to be consistent in their delivery and predictable in their results.
One of the single biggest problems in the software industry is the haphazard nature of releases. Customers often don’t know when to expect a new release and as a result are unable to do any planning in advance. This leads to customers frequently ignoring new releases unless they contain critical security fixes or highly desirable features.
Prior to 2003, Microsoft was severely criticized for releasing software patches at random, often catching major customers by surprise. It adopted a consistent and predictable release schedule for Windows and Office security patches in 2003. The regular schedule makes it much easier for everyone to plan ahead and stay up to date. Out of sequence patches are still needed on occasion but they are relatively rare.
Companies like Salesforce.com and Canonical (Ubuntu Linux) issue major new releases on regular schedules. The contents of every release are not pre-determined. New features that are ready to go are included and those that miss the cutoff date are held until the next release. In essence, the feature set floats while time to market and quality level are fixed.
Can this approach work for everyone? There are exceptions to every rule, so the answer has to be no. However, my experience strongly suggests that the vast majority of customers prefer regular, predictable updates. They may not get all the features they want but they know they’ll get something of business value.
There are many ways to achieve consistency and predictability. The keys to success are setting priorities and establishing discipline.
Priorities and Discipline
Candidate features (preferably in the form of stories or use case scenarios) must be prioritized. Everyone on the team must be willing to accept that not every candidate feature will make it into the next release, even if it is marked as high priority. Why? The target date and the quality level will be maintained. If a high-priority feature proves to be overly complex or places the release at risk, it will be removed from (or disabled in) the build.
Establishing discipline is a matter of ensuring that everyone understands the goals and is committed to achieving them.
This approach may be awkward at first, especially for groups that are accustomed to making huge commitments and working hard for however long it takes to deliver. When releases are 6-, 12-, 18-months, or more in duration, having a feature miss a release is a big deal. When releases are 1-, 2- or 3-months apart, it’s not such a major concern.
Give it a try. I’ll bet you’re pleasantly surprised at the positive reaction from your customers. What do you think? Have you tried it?