Agile development increases business value for the customer, with the customer controlling the variables at each iteration. Ken Schwaber, co-creator of the Scrum agile approach, explains the basic notion behind agile development. A number of useful links appear at the end of the article.
Agile development increases business value for the customer, with the customer controlling the variables at each iteration. Ken Schwaber, co-creator of the Scrum agile approach, explains the basic notion behind agile development. A number of useful links appear at the end of the article.
Agile processes compose a new form of software development (see www.agilealliance.org). Founded on an empirical model of process control theory, agile processes deliver value iteratively and incrementally. Customers and development teams collaborate to wrest the greatest value from advanced technologies and emerging requirements. We call this value driven software development.
The four variables that control software development projects are the cost, the date of delivery, the quality, and the functionality. The traditional approach to software development attempts to fix these at the start of the project to form a contract between the customer and developers. The contract can be paraphrased, "If you budget this much money, on this date we will deliver a system to you with this functionality and acceptable quality." To reach these contractual details, requirements and architectures are nailed down and used to create plans and estimates.
Once the project starts, changes happen. The technology requires different approaches than anticipated. The business environment in which the system will be implemented changes. As the customers think about the system, they change what they believe will provide value. As described by Ralph Stacey in his book, Strategic Management and Organizational Dynamics - The Challenge of Complexity, 3rd Edition (Pearson Education, Feb. 2000), the more uncertain the technology and the less the requirements are understood, the more changes will occur.
The modified Stacey graph below projects the degree of change that will be required as a project proceeds.
For example, mainframe batch system development is associated with simple, low-change projects. At the other end of the scale, N-tier, Web-deployed wireless technologies are associated with complicated or complex, high-change projects. The higher the complexity, the higher the degree of change one can expect.
In a traditional development project, constrained by a contract fixing cost, date, functionality, and quality, changes either are deferred until after the initial system is delivered or extensive change management processes are used to adjust the four aspects whenever a change is requested. This results in systems that don't provide the business value because they are out of date. Worse yet, it may result in systems that are never delivered because they are embroiled in the change management process. Agile processes avoid this dilemma by embracing the expected changes through value-driven project management.
To customers, business value is a function of their choice of cost, quality, time, and functionality:
business value = f(cost, time, functionality, quality)
Value driven projects leave the determination of the four variables in the customer's hands throughout the project. The customer only commits to one iteration, usually of thirty days or less. The customer authorizes development iteration by iteration, and is free to change any of the variables based on progress to date and the business value that is provided. For instance, if deregulation occurs to an energy company project, the requirements may significantly change from the previous iteration.
Rather than contracting, the customer and development team collaborate to achieve business value. Prior to each iteration, the customer identifies the highest priority requirements that will create business value. The team identifies how many of these requirements can be turned into a product increment that delivers that value during the next iteration. The team then proceeds for one iteration, doing their best to create this business value. The only deliverable required from the team is live, demonstrable business functionality working on a computer.
At the end of the iteration, the customer reviews the working system functionality with the team. Based on the review, the customer can
- Reprioritize and change the next set of top-priority requirements
- Request that the demonstrated increment be delivered as a working system
- Increase the cost of future iterations by requesting that additional teams work on the product backlog
- Adjust the quality to increase or decrease the amount of functionality delivered in an iteration
- Not fund additional iterations because the business value received for the cost is inadequate
In any case, the customer controls the variables and is free to change them at the end of every iteration. The customer controls the project, guiding the work to deliver what constitutes business value. The ability to actively review what the team produces at every iteration greatly helps the customer make this determination. In this way, value driven development gives the customer flexibility. The customer is provided with the tools to maximize the business value produced with every iteration, and business value can be refocused before each new iteration.
Agile processes employ value driven development to increase the success of development projects. Side benefits include development team satisfaction, awareness of the business that they support, and reduced costs (since only the code that is needed is built).
Value-driven software development was described by James Bach in Process Evolution in a Mad World at Software Quality Week, 1994 (look for it under "Articles" at www.satisfice.com)--and by Ken Schwaber in Controlled Chaos, at OOPSLA in 1995. Since then, value driven software development has been incorporated into all of the agile processes, although the approach varies by process. However, collaboration between customer and development team is the common thread among all of them.
Agile methods and value driven software development are also described at the following sites:
- Scrum
- Extreme Programming
- Dynamic Systems Development Method
- Feature Driven Development
- Crystal Approach (www.crystalmethodologies.org
And in two recent books:
- Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, by Jim Highsmith. (Dorset House Publishing, 2000. ISBN: 0-932633-40-4)
- Agile Software Development with SCRUM, First Edition, by Ken Schwaber and Mike Beedle. (Prentice Hall, 2002. ISBN 0-13-067634-9
