Is Agile Software Development Cheaper? Depends on What “Cheaper” Is
I read an excellent discussion of "Is Agile Software Development Cheaper" by Kennith Grant. This discussion was similar to one I had last week myself. He pointed out that the typical answer "we will deliver every few weeks and not building features people don't want" was the normal answer but that really didn't answer the CEO's question. Cheaper in the CEO's context "cheaper” means "a project can be completed with the same or smaller amount of people for the same or shorter length of time"
AGILE VERSUS WATERFALL IS LARGELY APPLES TO ORANGES: “If we have a software product with a known and unchanging scope and all other things are equal, will it be cheaper to deliver the product in its entirety using an agile methodology rather than using waterfall?” The short answer to this question is no. Agile has, especially with Scrum, a degree of ceremony, and in this make-believe scenario that would get in the way of pure analysis, design, build, test, etc. As you can see, this degree of ceremony would slow things down, hence making a project more expensive.
But the real questions should be more like "if rather than building the program in its entirety, we build only the critical functionality and reduce rework the answer is different.
AGILE USUALLY CHEAPER IN THE REAL WORLD: If we build functionality the user wants and with feedback so we stay on course is the program cheaper... LIKELY
STANDISH FOUND MUCH WATERFALL FUNCTIONALITY NOT NEEDED: The Standish Group once found that when requirements are specified early in the lifecycle, 80 percent of the functionality is relatively unwanted by users with 45 percent never used, 19 percent are rarely used, and 16 percent are sometimes used.
VIABLE COST & SCHEDULE ESTIMATES ARE POSSIBLE FOR DECISION MAKING: But in answering this question from a pragmatic view, estimation IS needed up front to understand the probable scope and the range of cost and schedule. For programs of any substance management needs this information to make proper decisions. I sometimes hear agile people say something like "can be done at any time, will deliver constantly, and can't tell you when the customer will have achieved their full business value. " Further, I have seen Agile programs that took their user stories, assumed this was the complete list up front and forgot all the volatility designed into an Agile program, with change encouraged and new / changed user stories likely coming up regularly.
CHEAPER NEEDS TO CONSIDER TOTAL OWNERSHIP COSTS, NOTE JUST DEVELOPMENT: Again, developers are rightly concerned with development, not maintenance. But what about the C level... If something can be developed using Agile but is a nightmare to maintain (we did minimalise on documentation, for example) we may be bloating the maintenence portfolio with surprises. And management hates surprises. Using SEER one can evalaute both development and maintenance.
Some of the risks that are often ignored and should not be:
- Using User Stories as size doesn't mean they won’t grow / change
- Requirements volatility can be even more drastic (design on the fly)
- Risk of lack of integration / regression testing from sprint to sprint
- Requirements growth due to regular wish lists
- Poorly constructed user stories may require modifications
And some of the SEER parameters that model Agile are:
- Requirements Formality
- Requirements Volatility
- Personnel Capabilities – Analyst and Programmers
- Familiarity with the Process
- Process Maturity
- Staffing Complexity
- Development System Volatility
- Automated Tools Usage
- Testing Level
- Quality Assurance Participation
Recent briefing covering Agile methods and modeling Agile cost, schedule, and risk
Here is a link to Kenneth Grant's blog "Is Agile Cheaper"