It's no secret that the state of the economy and disruptions in capital markets have impacted many companies, large and small, during the first few months of 2008. This March, Gartner advised that CIOs must prepare to cut IT costs in order to cope with the tightening economic environment.1 Software development projects, especially those of the exploratory, dynamic, forward-leaning sort where Agile methods really shine, are being frozen at current levels and even deferred entirely until the business climate improves. Some teams have undergone reductions in workforce, and thus losing valuable domain and project knowledge.2
These uncertain times have provoked some software managers and executives to return to their comfort zones, which is understandable. Most of us seek familiarity and security when under threat, whether comfort food or a cozy bed. However, in the software development context, seeking comfort should not include pulling back from Agile methods and returning to more traditional, heavier-weight, plan-oriented methodologies. Unfortunately, we at SourceIQ and others have witnessed some IT managers and executives do just that.
The challenge for Agilists is to understand where managers and executives are coming from, recognize the power of Agile techniques during times of upheaval, and be prepared to engage in a balanced, reasoned discussion with software managers as to the benefits of staying Agile.
This article examines Agility in terms of tools that can assist you in pursuing this sort of discussion:
- Agile's potential to deliver superior Return on Investment (ROI)
- Agile's ability to drive down Total Cost of Ownership (TCO)
- The importance of trust in making the business case for Agile
I will explore these topics in depth, and suggest ways we can keep our software projects moving in a positive and progressive direction.
When the going gets tough...
"In tough economic conditions, companies are concerned about revenue growth. You need to protect revenue, but you also need to control operating expense. IT comes up on the expense radar and is usually whacked. In a time of crisis, companies typically revert to treating IT as a cost, and they put it under the CFO and get into cost-containment mode."3
Cost-containment tends to tumble downhill and land on the desks of managers, stimulating fear, uncertainty and doubt about Agile techniques. Management becomes motivated toward restoring the old regime as a list of issues with Agile emerges: Agile is risky; business unit customers require a more predictable delivery model; Agile projects and teams are too hard to manage. When pressed, some will admit that the prospect of heightened rewards from Agile fit their risk profile during "good times," but now the heavier-weight approaches to which they are returning seem preferable even if they don't really offer a better answer. Feeling pressure to do more with less and contend with a challenging project climate, some managers lose confidence in Agile and seek the comfort and perceived advantages of increased status reporting, waterfalls, and neatly staged sequences of clearly documented project phases.
Agile practitioners typically respond to these threats with a list of qualitative benefits. Customer satisfaction among end users seems to improve when priority features become available in a shorter timeframe. Relationships with business unit counterparts become more open, engaging, and productive. Team morale is improved when good software gets delivered and used. Performance and robustness of systems in production is better. Customer support calls from VIPs -- Very Irate Persons -- are down.
But it's important to remember that when the going gets tough, the bean-counters sharpen their pencils. If you're experiencing a climate where management may be pulling back from Agile and moving towards more traditional, plan-driven methods, you should be able to defend the economic benefits of Agile with sound, management-oriented business cases. It's not enough to think like an "Agilista." Get out of your own skin and set your sights on the Big Picture. The best way to sell your argument is to demonstrate that it's in the best interests, organizationally and career-wise, of those managers and executives you seek to convince.
The economic benefits of Agile can be made with three business cases, each of which strongly argues in favor of Agile over more traditional approaches: return on investment (ROI), total cost of ownership (TCO), and improved competitiveness in the market. Any one of these arguments may be enough to stay on track with Agile; the combination of all three is overwhelming.
Return on investment (ROI)
ROI represents the economic benefit of a given investment. It is calculated as a ratio of the money gained or lost on that investment relative to the amount of money invested, and is typically stated as a percentage rather than as a dollar value. For software development, the return is typically related to the sales or income derived from the software product.
Agile projects geared towards driving new revenue are well-suited to an ROI assessment. Will your project attract new customers, or deliver a new product that will create incremental sales to existing customers? Will your company gain by entering a new market or increasing existing market share? If your company is making an investment and devoting a portion of capital to a speculative venture with the hope of a positive outcome, then an ROI assessment is likely to be in store for you.
Articulating the superior ROI potential of Agile over traditional, plan-driven approaches may give you the opportunity to advance the business discussion from the subjective ("things are better with Agile") to the objective ("Agile increases ROI by x%"). A sound business case is a powerful tool for staying Agile when others may want to revert back to a flawed but familiar comfort zone.
Depending on how deep a dive you plan to take on ROI, it may be helpful to come up to speed on financial terms that often enter into an ROI discussion. Determining the return may involve gross sales, net income, revenue recognition, cash flow, and the time value of money. You don't need to become an overnight financial guru; after all, understanding the subtleties of accounting and financial statements can be a lifelong pursuit. But business has its own language, and few hours with a browser can help you grasp the basics.
The investment side of ROI can be easier to nail down than the return, as it boils down to what it costs to build and maintain the software product. This investment can include personnel, benefits, facilities, equipment, utilities, software licenses, and so on. As you look at the ROI for a project, product, or team, keep in mind that the costs should be apportioned fairly. If personnel are applied to multiple projects, or if infrastructure costs are spread across teams, this should be reflected in your ROI model.
Let's look a three variations of an Agile ROI model. As we walk through these examples, notice that ROI is an equation with two variables. Changing one, the other, or both impacts the outcome. Consider which of these variations most closely matches the conditions of your project, and how that model might be adapted to your needs.
ROI variation 1: Cost reduction, constant return
In this example, I'll illustrate the ROI benefit of Agile in terms of its impact on reducing costs. Imagine that your company has sold a software product for $1 million. It doesn't matter how the product is developed: the deal has already been done and the return will be the same. Knowing this, your opportunity for improving the bottom line and thus the ROI is to show the superior operational efficiency of Agile.
The differences between the Agile and plan-driven ROI models are subtle, but they have a large impact. One difference is that you can assert, for instance, that the plan-driven approach will extend our project duration from twelve to fourteen weeks, an increase of two weeks. This difference can be formally expressed using models like COCOMO II4: "[t]he time to deliver new or changed system capabilities is a function of system complexity, the process used to affect the changes, the skills of the practitioners who are making the changes, and the tooling that is available to automate work."5 Alternately, you may empirically reflect on the additional time needed to thoroughly capture and review requirements, project plans, acceptance test criteria, and other required artifacts. The other difference you can assert is that the plan-driven approach will require a larger team, with additional onshore resources to manage requirements and plans, and conduct formal liaison with business unit counterparts, and additional offshore resources to manage the offshore team. Figure 1 illustrates the details of this comparison.
Figure 1: Reduced costs, constant return
These assertions and differences are for illustrative purposes only. No doubt your own modeling exercises will bring in different project compositions, cost structures, team sizes, and so forth. But if you are an Agile proponent, it's likely that you have first-hand experience with how a small team can outperform a large team and deliver superior software in less time. An ROI model is your vehicle for expressing this experience in a way that makes sense to people who might otherwise not be all that interested in a debate on methodology.
ROI variation 2: Constant cost, increased return
Under this second scenario, you are in charge of a team whose size is fixed, and so the investment that will be made in your project is also fixed. You're going to spend "$x" no matter what approach you adopt. This situation is common to large organizations that establish budgets well in advance of performing projects.
Your experience tells you that Agile will yield a greater return than a plan-driven approach. Your basis for this argument is that Agile focuses on delivering working software that puts the priority on customers' most keenly required features. You've run this by some sales staff, maybe even some customers, and can now quantify the increased sales opportunity that will be created by a software product that better meets the customers' needs.
As illustrated in Figure 2, we start with the same team composition as given in ROI Variation 1: six onshore staff, and six offshore staff. The project costs are fixed, so your ability to improve ROI will come solely from how much your methodology can drive increased revenue. Based on your market research, you believe that an Agile focus on customer requirements will increase return by 20% over a plan-driven project with the same team, through more customer orders, a higher price point, or both.
Figure 2: Constant cost, increased return
ROI variation 3: Cost reduction, increased return
Many organizations that have adopted Agile are breaking new ground with their software development. Their focus is on new applications, services, and components, and not on pulling massive legacy applications into the 21st century. They are driving markets and growth through competitive product offerings.
These projects are ideal for illustrating Agile's superior ROI potential. When you can demonstrate Agile's ability to deliver the higher return shown in ROI variation 2 above, coupled with the operational efficiency and relative cost savings shown in variation 1, you achieve an ROI gain at both ends of the equation.
Consider the model illustrated in Figure 3. It brings together the team dynamics of model 1 with the revenue considerations of variation 2. The ROI that Agile can deliver is striking, and will give even a risk-averse manager a powerful reason to reconsider retreating to traditional, plan-driven approaches.
Figure 3: Cost reduction, increased return
When ROI is at risk
No discussion of ROI is complete without also examining how risk influences decisions and outcomes. When we are assembling an ROI model, we can lose sight of the fact that the predicate for the exercise is an investment, and that investments inherently carry an element of risk.
Managing risk is not the exclusive dominion of bankers and venture capitalist. All savvy investors are intimately aware of risk. Whether you're setting up a 401(k), looking at a rent-versus-buy decision, or considering whether to purchase a new car or a used one, you typically examine the potential upside and downside associated with your investment. You must have some ability to manage risk, to understand when you are over-exposed, and to stay within your tolerance for risk. All these abilities are fundamental to taking advantage of the good times and weathering the bad, and you can bring that experience to a discussion of software ROI.
Software projects, like investments, carry risk. The upside is that when our project succeeds, we make our numbers, everyone is happy, and we move on to further returns. The downside is that when the project fails, the investment is lost. Worse yet, there is an opportunity cost for the other projects that might otherwise have been funded but are now lost opportunities.
There is a substantial and growing body of trade literature on the benefits of Agile versus other approaches when it comes to risk. Agile's focus on open and effective communication with customers, combined with iterative delivery, has yielded project success rates averaging 70%6 (and some organizations report success rates even higher). By contrast, some studies have found that project failure rates for traditional approaches can run as high as 60% to 85%.7 So even in the unlikely case that your modeling shows the same ROI for Agile and plan-driven approaches, the fact that Agile creates a greater likelihood for success is a key factor in achieving that ROI.
We also have to acknowledge that some software projects are simply doomed to failure. Our job is to do whatever it takes to achieve success, and we can get so wrapped up in what we're doing that we forget to think like an investor. But good investors have a valuable skill that translates into an important, but perhaps understated, benefit of Agile: they know how to cut their losses.
With Agile, you can usually tell faster that your project is going nowhere. In uncertain times, this point is worth reinforcing with managers. Agile gives them better tools for applying course corrections to the project, or cutting their losses entirely. Waterfall is often touted as being more predictable, but unfortunately the prospect of achieving the predicted result often fails to emerge until the late stages of the project. Nobody starts a software project planning to fail, but discretion truly is the better part of valor if things start coming apart. Agile offers management that discretion.
Total Cost of Ownership (TCO)
IT metrics guru and industry leader Dr. Howard A. Rubin offers a powerful perspective on how benchmarking technology costs must come both from the top and the bottom:
"From the top, you really have to understand your technology costs -- the costs of your technology goods and services -- almost as if you were a manufacturing company. You have to understand the cost structure of technology, what its impact is on your margin and what the impact of your technology investment is on growth, shrinkage, and market share. And you have to integrate your understanding of the cost structure and performance structure of technology directly into the company's financials."
He goes on to say, "[F]rom the bottom, you really have to understand a lot about technologies and about the technology organization itself. That means much more than just knowing how long it takes to develop an application... It means you need to look at technology as a commodity, at the unit costs."8
Managers and executives examine total cost of ownership (TCO) from the top down. But in order to factor the benefits of Agile from a TCO perspective, we need to work from the bottom up, and meet management halfway.
TCO is the most common mode for analyzing "keep the lights on" systems -- i.e., the production IT systems that power modern commerce, whether through customer interaction or back-office systems. As software goes through its lifecycle, from new development to mature system in maintenance mode, the economics shift from ROI to TCO.
As discussed earlier, Agile is often seen as a set of techniques for new development, but it offers tangible benefits for TCO and mature systems as well. Software maintenance is framed by fundamental Agile concepts: working from a backlog of prioritized tickets or engineering change orders, and delivering incremental releases of working software. The team dynamic is also in place: many software maintenance teams work together for years, adopting their own notions of a lightweight, responsive methodology. The conditions for maintaining mature systems are often ripe for an Agile approach.
TCO in detail
Accepting that Agile can be appropriate for "keep the lights on" systems, how does it play in a TCO analysis? Compared to many other industries, software development is light on equipment and heavy on personnel. Personnel costs represent 50% to 70% of typical project costs. Generally speaking, Agile can streamline personnel requirements, removing the personnel overhead that one typically sees with traditional, plan-driven approaches. This delivers direct financial benefit in terms of TCO.
Figure 4 projects the cumulative team cost over time for two teams, one Agile and one plan-driven. The team composition and cost structure is given in the "ROI Variation 1" model above.
Figure 4: The cumulative team cost over time for two teams, one Agile and one plan-driven
Agile can definitely help contain costs and improve TCO. In the Figure 4 example, the cost savings exceed $750,000 per year, a 64% reduction from the plan-driven estimate. Does this sound far-fetched? It's not. The model given here is an amalgam of real-world maintenance projects that have shifted from waterfall methodologies to Agile.
This bottom-up focus on team composition can show strong reasons to stay Agile, now more than ever. Build the model that makes sense for your system, team, and personnel cost structure. Be aware of the work of others who've gone before you,9 and how you can leverage those lessons learned in your business case.
It's also important to note that reducing team size can have far-reaching effects beyond what I've shown here. Smaller teams mean less equipment, fewer software licenses, less office space, less heating and cooling. Agile's embrace of unit-testing, test automation, and continuous integration drives quality and productivity up, and costs down. Smaller teams mean fewer moving parts, improved communication, and greater opportunity for flexible work conditions. These factors work in favor of maintenance teams that work in a "virtual bullpen," with team members in different parts of the world; improved daily communication can reduce the number of required site visits. Each of these benefits speaks to operational efficiency and brings along its own advantage in cost savings.
Challenging economic climates make it imperative for companies to increase their focus on retaining existing customers and attracting new ones. In a highly competitive market, demand for customers grows and margins often shrink. If your company relies on proprietary software to transact business with customers, drive customer growth, or support customer satisfaction, then executives and managers will want to know how Agile can enhance competitiveness and the customer experience.
Modeling this impact typically begins with qualitative assessments. For example, does Agile help retain key large customers by delivering vital new functionality faster? Perhaps Agile's quick turns enhance software quality, leading to improved customer satisfaction?
If you've already made a sound financial case based on ROI or TCO, a discussion of improved competitiveness may be icing on the cake, and you can leave it at that. However, with a bit more homework and digging, especially in coordination with sales and support personnel, you should be able to derive an estimation model for the financial impact of improved competitiveness, ideally folded into your ROI model as additional potential return.
Opening up the process through trust
"Most IT departments do not have effective communication and marketing programs. Again, in business history, these organizations are young, and their strategic value is clouded and not clearly articulated. Most technology people revert and talk about things in technology terms."10
A sound business case is predicated on common sense, financial impact, and a proven process that delivers results. But there is another key ingredient to a sound business case that can trump all the rest: trust.
In making the case for Agile in an uncertain economy, our focus needs to be on management as much as it is on development. That focus doesn't always come naturally. Software development can be elegant, inspiring, and especially all-consuming. At one time or another, most of us have experienced the concentration and immersion required to deliver a great software project; the intensity moves everything else to the back-burner, including the reports on status and progress to management.
Software development is a team sport. The team includes developers, designers, architects, testers, and release engineers. It also includes customers, business unit counterparts, and program managers. The team includes other forms of management, too: project managers, development managers, quality assurance managers, as well as executives from directors right up to the VP of product development or the CIO.
As it is practiced today, Agile tends to have the greatest impact on those closest to the code. The further we get from the code, the less the impact -- to the point where it is still fairly common for customers, business unit counterparts, and executives to not really care all that much about the nuances of Agile, as long as it delivers results.
So in an uncertain economy, staying Agile may well boil down to reaffirming trust relationships. As Agilists, we frequently say to our customers and management, "Trust us." Yet we de-emphasize the tools that customers and managers have traditional used to measure progress towards goals, such as project plans, contracts, and formal status reporting. If those we serve have limited visibility into our process, how can we foster a strong and enduring trust relationship?
The answer is to open up the process. Transparency is a powerful tool for engaging customers and managers, and enhancing the development process with the perspectives and inputs that are their responsibility and prerogative. Clearly, Agile is oriented around results: incremental delivery of working software that prioritizes customer requirements. But we can't get caught in the trap of a single-minded focus on delivery. Delivery is not process, it is outcome. Process reveals how you achieve that outcome.
My earlier articles on Key Performance Indicators11 (KPIs) and the Goal-Question-Metric (GQM) approach12 recommend tools that you can use to engage the full span of talents in the organization in a meaningful software development process. These tools can be used to create portals of management metrics that automate process transparency, as well as compliance with lean development governance standards. Further, there is an increasing set of Application Lifecycle Management (ALM) products13 that can apply and automate these tools, letting you deliver transparency without burdening Agile teams with time-consuming reporting tasks. To truly maximize the Agile advantage in a troubled economy, open up the process to managers and developers alike, and earn trust by not only delivering results, but also demonstrating a stable, organized process for delivery.
- "Gartner Recommends Key Cost-Cutting Tactics in Data Management and Integration," Gartner press release, 3/10/2008 (http://www.gartner.com/it/page.jsp?id=619108)
- "[E]ven with 2008 budgets approved and IT decision makers looking forward to improving IT resources in the coming months, the greenlighting of actual technology investments will depend on the overall economic environment, which remains uncertain." from "IT Decision Makers Offer a Little Hope for 2008," CDW IT Monitor news release, 3/5/2008.
- "The Cost Of Bad IT Economics," CIO Insight, 2/11/2008.
- Software Cost Estimation with COCOMO II, Barry Boehm, et al, Prentice Hall PTR, August, 2000.
- "Improving Software Development Economics, Part I: Current Trends," Walker Royce, The Rational Edge, April 2001.
- "Defining Success," by Scott W. Ambler, Dr. Dobb's Portal, 10/31/2007 (http://www.ddj.com/architect/202800777)
- Multiple references; see "Waterfall Method: A Colossal Blunder!," Jeff Sutherland, 10/7/2004.
- "A CAI State of the Practice Interview with Dr. Howard Rubin," The IT Metrics and Productivity Institute, January, 2006.
- Many Agile experts have written and spoken on TCO; Scott Ambler (Practice Leader Agile Development, IBM) and Jeff Sutherland (co-creator of Scrum) are two notable industry experts.
- "The Cost Of Bad IT Economics," CIO Insight, 2/11/2008.
- "Development governance for software management," The Rational Edge, 10/16/2007 (http://www.ibm.com/developerworks/rational/library/oct07/dunn/index.html)
- "Achieving governance goals with GQM," The Rational Edge, 3/15/2008 (http://www.ibm.com/developerworks/rational/library/edge/08/mar08/dunn/index.html)
- See, for instance, Part 3 of "Application lifecycle management with ClearQuest 18.104.22.168" in this issue of The Rational Edge.
- Participate in the discussion forum.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
- Global Rational User Group Community