The Business Value of Agile Software Methods

Maximizing ROI with Just-in-Time Processes and Documentation

David Rico, Hasan Sayani, Saya Sone

• Publisher: J. Ross Publishing
• Year: 2009
• Print ISBN: 9781604270310
• eBook ISBN: 9781604276763
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

Whether to continue using traditional cost and benefit analysis methods such as systems and software engineering standards or to use a relatively new family of software development processes known as Agile methods is one of most prevalent questions within the information technology field today. Since each family of methods has its strengths and weaknesses, the question being raised by a growing number of executives and practitioners is: Which family of methods provides the greater business value and return on investment (ROI)? Whereas traditional methods have been in use for many decades, Agile methods are still a new phenomenon and, until now, very little literature has existed on how to quantify the business value of Agile methods in economic terms, such as ROI and net present value (NPV).Using cost of quality, total cost of ownership, and total life cycle cost parameters, The Business Value of Agile Software Methods offers a comprehensive methodology and introduces the industry's initial top-down parametric models for quantifying the costs and benefits of using Agile methods to create innovative software products. Based on real-world data, it illustrates the first simple-to-use parametric models of Real Options for estimating the business value of Agile methods since the inception of the Nobel prize-winning Black-Scholes formula. Numerous examples on how to estimate the costs, benefits, ROI, NPV, and real options of the major types of Agile methods such as Scrum, Extreme Programming and Crystal Methods are also included. In addition, this reference provides the first comprehensive compilation of cost and benefit data on Agile methods from an analysis of hundreds of research studies. The Business Value of Agile Software Methods shatters key myths and misconceptions surrounding the modern-day phenomenon of Agile methods for creating software products. It provides a complete business value comparison between traditional and Agile methods. The keys to maximizing the business value of any method are low costs and high benefits and the business value of Agile methods, when compared to traditional methods, proves to be very impressive. Agile methods are a new model of project management that can be used to improve the success, business value, and ROI of high-risk and highly complex IT projects in today's dynamic, turbulent, and highly uncertain marketplace. If you are an executive, manager, scholar, student, consultant or practitioner currently on the fence, you need to read this book!

1

---

Introduction to Agile Methods

---

Agile methods are an important new paradigm for maximizing the business value of creating new software products. They are part of the fields of innovation, new product development, systems engineering, and software engineering. Agile methods are a contemporary form of concurrent engineering, cross-functional teams, and overlapping development. They are useful for creating software products in both the commercial marketplace as well as the government sector, particularly for rapidly developing innovative product ideas.

Consisting of right-sized, just-enough, and just-in-time processes and documentation for developing software, agile methods have just enough discipline to capture customer needs, plan projects, and develop high-quality software products. Focused on creating software products that satisfy customer needs without unnecessary bureaucracy, they are the perfect tool for maximizing business value by rapidly responding to market needs with innovative solutions. Agile methods are a win-win solution for most stakeholders.

Agile methods bring high-quality, innovative software to market in the fastest and most cost-effective manner, solving issues such as how to: (1) innovate, (2) manage product development, and (3) ensure quality. Rather than a 19thcentury, industrial-era manufacturing process, they are a customer-focused way to develop products and an efficient alternative to traditional document-driven process improvement and systems engineering standards.

1.1 What Are Agile Methods?

Agile methods are contemporary approaches for creating new software based on customer collaboration, teamwork, iterative development, and response to change. Combining communication and interpersonal trust with a flexible management and development framework, they contain just enough process to capture customer needs in the form of user stories and to rapidly create working software. However, the keys to agile methods are rich, high-context communications with customers along with cohesive teamwork.

There are numerous forms of agile methods, such as Extreme Programming, Scrum, Dynamic Systems Development, Feature Driven Development, Crystal Methods, and many more. Open source software is also considered an agile method. Four values are common to all agile methods: (1) customer collaboration, (2) teamwork, (3) iterative development, and (4) adaptability. Each of the major types of agile methods embraces these values in a unique way. However, it is the best elements of each that represent the body of knowledge for agile methods.

For instance, Extreme Programming utilizes the practices of release planning, user stories, pair programming, and much more. Scrum brings us backlogs, sprints, daily standups, and retrospectives. And open source software uses right-sized, just-enough, just-in-time documentation and collaboration. Although proponents of each feel their method is sufficient for software development, it is the basic premise of this book that the best practices among all of the methods represent the essence of agile methods. Furthermore, this book posits the notion that the values of agile methods outweigh the rules and practices of any one agile method. And we are not alone in that viewpoint.

1.2 Why Agile Methods Emerged

Agile methods emerged in the 1990s for a specific reason: to successfully create new software that satisfies customer needs. Agile methods are really the convergence of multiple phenomena: inexpensive computers, powerful and easy-to-use information technologies, and the desire to succeed. Agile methods are also the result of a convergence of technologies: large process improvement models, large software engineering standards, and large methodologies. Although the creators of agile methods tried to use these large models, standards, and methodologies to create new software products, these projects failed time and time again.

This was an auspicious beginning for what we now know as agile methods. When agile methods were born, large software engineering models, standards, and processes were getting even larger. Rapid Application Development, the Software Capability Maturity Model^®, and IEEE standards were hitting their stride with more to come. Traditional methods were based on documented project plans, large-requirements documents, and multi-year project life cycles. However, traditional approaches to software development based on manufacturing processes led to minimal project success. Not even the good ones based on earned-value management and quality-control processes, resulting in zero defects seemed to help.

From 1991 to 1998, at least five major types of agile methods emerged to help projects succeed in lieu of the old ones: Crystal Methods, Scrum, Dynamic Systems Development, Feature Driven Development, and Extreme Programming, in that order. It was a quiet counter-revolution to mega-standards such as the Software Capability Maturity Model^® and IEEE standards, against which agile methods were pitted.

1.3 How Agile Methods Emerged

At first, the creators of agile methods attempted to use some of the early traditional methods to manage their software projects. However, these were ineffective, projects were failing, and the creators of agile methods weren’t obtaining new business, which often led to lawsuits. Thus, the creators of agile methods started with a clean slate, threw away the old methods, and did what was necessary to succeed. One of the first agile methods was Scrum, which was based on product backlogs, sprints, daily standups, and product owners, and which adapted ideas from new product development approaches from the 1980s, such as iterative development and teamwork.

With an odd mix of customer interaction, iterative development, teamwork, and not much more, Scrum projects began to succeed. Scrum opposed the major values of traditional methods: contracts, processes and tools, documentation, and project plans. Project success was a major result of agile methods such as Scrum, because it was created to save failing projects. Success within traditional methods used manufacturing metrics, such as effort, cost, productivity, schedule, quality, and reliability. However, the creators of Scrum valued project success much more, because it translated directly into customer satisfaction.

The creators of Scrum felt that detailed project plans, requirement documents, and methods didn’t contribute to successful projects. Instead, they advocated requirements, such as informal features, product backlogs, and sprints, as well as project plans, such as release and sprint plans. They believed in processes, as long as they didn’t stand in the way of delivering valuable software in 30-day sprints. However, Scrum’s creators felt that documentation led to poor communication and that informal daily standup meetings and sprint reviews were a far better alternative.

1.4 First Agile Methods

Crystal Methods came to light as an offshoot of object-oriented methodologies from the 1980s merged with other agile practices. Created in 1994, Dynamic Systems Development, an offshoot of Rapid Application Development, was classified as an agile method, as was Feature Driven Development, an object-oriented method created in 1997 to save failed projects. Extreme Programming, originating around 1998, was clearly the capstone of the era of the 1990s when agile methods emerged. Extreme Programming was a confluence of Scrum, Participatory Design, Rapid Application Development, and many others.

Extreme Programming was created to save a failed payroll system at the Chrysler Corporation. There is some evidence to show that Scrum may have been used as a basis for the creation of Extreme Programming, which was an amalgamation of practices, including release planning, user stories, test-driven development, refactoring, pair programming, and onsite customer. In 1999, Extreme Programming was introduced to the masses, and the rest, as they say, is history. Although Extreme Programming seemed to enter the scene with a whimper rather than a bang, it soon became the favorite among methodologists.

In 2001, 17 methodologists gathered to discuss agile methods and their newfound success, and to decide the future of agile methods. They defined the Agile Manifesto consisting of four major values: (1) customer collaboration over contract negotiation, (2) individuals and interactions over processes and tools, (3) working software over comprehensive documentation, and (4) responding to change over following a plan. Although these values seem superficial, they represented a fundamental revolution in software engineering. They are not just opinions but engineering principles.

1.5 Agile Methods Explosion

Four key events precipitated the explosion of agile methods: (1) the creation of Scrum; (2) the creation of Extreme Programming; (3) the emergence of Crystal Methods, Dynamic Systems Development, and Feature Driven Development; and (4) the creation of the Agile Manifesto. However, the marquee event had to be the publication of Extreme Programming in 1999. Extreme Programming did three things: it (1) promised project success, (2) introduced 13 simple practices, and (3) was a big departure from traditional process-and document-driven methods.

The international community was yearning for something new, and Extreme Programming was the fulfillment of those basic desires. Since the 1950s, the software community had been applying traditional methods, and it simply couldn’t stomach another one. In particular, the Europeans took to Extreme Programming because it was well-suited to their culture of Participatory Design. They started pair programming, enlisting onsite customers, and knocked down the cubicle walls to open up the workspaces.

By 2002, approximately 67% of leading-edge software developers who elected to use methodologies preferred Extreme Programming. European, Canadian, and Middle Eastern universities began researching, teaching, and writing about agile methods. Conferences dedicated to agile methods sprung up overnight, attracting thousands. Hundreds of papers and 75 books emerged on various topics associated with agile methods. Over the years, Scrum has become the most popular agile method, and agile methods are being applied in ways not previously imagined.

1.6 Summary

Agile methods are fundamentally new approaches created in the 1990s for developing software and to save failing software projects. They are based on customer collaboration, teamwork, iterative development, and adaptability to change-values not unique to agile methods but common in the fields of innovation and new product development. In fact, Scrum was based directly on new product development paradigms and served as a basis for other agile methods. Agile methods amount to right-sized, just-enough, and just-in-time processes and documentation for creating new software products.

Agile methods stand in direct opposition to the values of traditional methods, such as contract negotiation, processes and tools, comprehensive documentation, and following a plan. More importantly, agile methods were created to ensure project success rather than simply adherence to industrial age manufacturing measures such as earned value, programming productivity, and defect density. Communication is valued highly within agile methods, whereas documentation is seen as the key to quality and maintainability in traditional methods.

Within the value of individuals and interactions are principles such as teamwork, interpersonal trust, and communication quality. Attributes such as talent, skill, experience, and programming ability are also buried deep within this agile method value. When you add this up, agile methods amount to extremely talented individuals; just-enough, just-in-time communications, processes, and documentation; and frequent software deliveries. This creates a double-loop feedback system, resulting in project success and maximum business value for all stakeholders. Agile methods fulfill what traditional methods simply cannot do.

1.7 Further Readings

Argyris, C. (1976). Single-loop and double-loop models in research on decision making. Administrative Science Quarterly, 21(3), 363–375.

Carmel, E., Whitaker, R. D., & George, J. F. (1993). PD and joint application design: A transatlantic comparison. Communications of the ACM, 36(4), 40–48.

DeGrace, P., & Stahl, L. H. (1990). Wicked problems, righteous solutions: A catalogue of modern software engineering paradigms. Englewood Cliffs, NJ: Prentice Hall.

Gane, C. (1987). Rapid systems development. New York, NY: Rapid Systems Development.

Greenbaum, J., & Kyng, M. (1991). Design at work: Cooperative design of computer systems. Hillsdale, NJ: Lawrence Erlbaum.

Martin, J. (1991). Rapid application development. New York, NY: Macmillan.

Millington, D., & Stapleton, J. (1995). Developing a RAD standard. IEEE Software, 12(5), 54–56.

Muller, M. J., & Kuhn, S. (1993). Participatory design. Communications of the ACM, 36(6), 24–28.

Wood, J., & Silver, D. (1989). Joint application design. New York, NY: John Wiley & Sons.

This book has free material available for download from the
Web Added Value™ resource center at www.jrosspub.com

2

---

Values of Agile Methods

---

Agile methods are somewhat unique in that they are based on a set of values and principles. In one sense, agile methods are an outgrowth of the plethora of rapid development methodologies emerging in the 1980s. Some of these software methodologies, notably Rapid Application Development and its successor, Dynamic Systems Development, came replete with their own manifestos, values, and principles. In effect, agile methods are a values-based, or a principles-based, development approach for creating new software products.

Five major types of agile methods emerged in the 1990s: (1) Crystal Methods, (2) Scrum, (3) Dynamic Systems Development, (4) Feature Driven Development, and (5) Extreme Programming. While some were direct spinoffs of rapid and object-oriented methods in the 1980s, others were simply spinoffs of one another. At first glance, the five major types have little in common. In 2001, the creators of agile methods came together to study the commonalities of their approaches and formed the Agile Manifesto.

The Agile Manifesto outlined four major values of agile ...

Table of contents

• Cover
• Title
• Copyright
• Dedication
• Contents
• Acknowledgments
• About the Authors
• Foreword
• Preface
• Web Added Value™
• Chapter 1— Introduction to Agile Methods
• Chapter 2— Values of Agile Methods
• Chapter 3— History of Agile Methods
• Chapter 4— Antecedents of Agile Methods
• Chapter 5— Types of Agile Methods
• Chapter 6— Practices of Agile Methods
• Chapter 7— Agile Project Management
• Chapter 8— Agile Software Engineering
• Chapter 9— Agile Support Processes
• Chapter 10— Agile Tools and Technologies
• Chapter 11— Comparison of Agile Methods
• Chapter 12— Agile Metrics and Models
• Chapter 13— Surveys of Agile Methods
• Chapter 14— Costs and Benefits of Agile Methods
• Chapter 15— ROI Metrics for Agile Methods
• Chapter 16— Measures of Agile Methods
• Chapter 17— Costs of Agile Methods
• Chapter 18— Benefits of Agile Methods
• Chapter 19— Return on Investment of Agile Methods
• Chapter 20— Net Present Value of Agile Methods
• Chapter 21— Real Options Analysis of Agile Methods
• Chapter 22— Business Value of Agile Methods
• Chapter 23— Agile vs. Traditional Methods
• Chapter 24— Future of Agile Methods
• Appendix
• Bibliography