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.

Failing Fast is a Good Thing

User Story Format Thoughts

Recently I posted about a common user story format. I’m starting to see more and more discussion about this user story format and how some feel that it is too constrained. One proposal was to swap the value and actor sections. I’m trying to figure out an example of how to write this, hence my problem with this format. It does not seem natural and I really don’t see the value.

One of the great concepts of Agile is to inspect and adapt. While right now I don’t see value in changing the standard user story format, it does not mean that there won’t be a day when someone proposes a better way or writing user stories. When that day comes, I’ll inspect the new format and perhaps adapt.

User Story Format Thoughts

Communicating Agile

Here’s a surefire way to fail with your Agile implementation. Ignore the other parts of the business that are used to dealing with schedule driven projects. It’s not enough to get the project team onboard with Agile, you need to spread the word and sell Agility to as many people as you can.

Go on “Agile Tours” and give multiple presentations about your Agile Team and how you are working to reduce waste and speed the delivery of working code. Of course short presentation won’t be enough to cover Agile Methodologies in much detail, but do talk about the benefits of customer interaction, process inspection, use stories, communication, UAT and so on.

Take the time to build the trust that what you are doing is correct and is the right thing for the business. Plus in today’s economy you are focusing valuable resources on the highest priority items and will deliver results sooner, who won't want to hear about that?

Communicating Agile