Agile Software Development

Traditional software development ("waterfall"), is plagued by predictable problems:  developers plan the next software release, then design, built, test, and release it, completing one phase before the next starts.  The entire process might take a year or longer, and by the time it is done, the product is not very good for one of two reasons:  either the technology has advanced, so that the software is obsolete before it is released, or the client's demands have changed, and they no longer want the product the developers have made.

Agile development, illustrated above, differs from the traditional approach by prioritizing and ranking changes, then taking them on one at a time.  By breaking the long development cycle into many short "sprints," each taking a week or so to complete, developers are able to deliver the most valuable changes immediately, and to adapt quickly to changes in technology or client preferences.  Clients get the changes they value more quickly and the developers can incorporate software innovations as they occur.  For example, Salesforce.com famously releases three model updates to its software each year.  

We can easily fit this into the problem-solving framework of Chapter One:

• Who is making the bad decision?  

Clients and Developers are jointly deciding how to design software that will be available in a year's time.

• Do they have enough information to make a good decision?

NO!  Clients don't know what their preferences are going to look like in a year and developers' don't know which capabilities are going to added to newer versions of the software.  

• Do they have the incentive to make a good decision?

Yes. 

Agile development mitigates the client's and developer's information problems by shortening the planning horizon to a week or so.   Clients rank which features are most valuable, and developers use the latest and best technology.  If client preferences or software changes, Agile development adjusts by the next sprint. 

HT:  Halley and Brian