Agile Project Management: Failing Fast is a Good Thing

One of the benefits of switching to agile project management methodologies is the opportunity to fail fast. As a point of comparison, think about how waterfall projects work. The business requirements are assembled into a software specification. The software development team reviews the specification, creates the design and builds the software product. (I know this is an oversimplification) Some months later the software development team proudly shows the customer the software application in all its glory.

History has shown that this moment is often a moment that is less happy than expected. Some part of the software specification was not delivered as the customer wanted, or it was delivered as the customer wanted, but it’s really the wrong thing. Bottom-line, the software project or a part of the software project failed late. Ouch… It’s going to be expensive to fix…

Agile methodologies by the way they work encourage failures very early in the project. With agile project management methodologies, there are frequent software product demonstrations to the product owner. Typically at the end of each sprint / iteration the software development team demonstrates the software build to the customer. Here’s the chance to let the product owner catch parts of the software project that are off course and make corrections as needed. It is much easier and cheaper to make a change on three weeks worth of software development after a sprint than six months worth of software development at the end of a waterfall project.

Show your software to the product owner, let them find problems and fix them. It’s better to have a software project fail fast resulting in small changes than fail late and have a big mess.