Managing for Value with Agile Software Development

[article]
Summary:
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

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!