In my last post, I said that I was committing to a dodeca-thalon of posts on the Agile Manifesto -- one for each Agile principle. I think this is great stuff that everyone should be exposed to. If you use Agile, or wonder why people are so hot for Agile, this series is for you.

And with that intro, here's #2 of 12

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Everything changes. Software is not set in stone, and even if it was set in stone, it would still change. So, we need a process that gracefully handles change. Part of this trick is by getting rid of the idea of a 12-week project, and instead having 12, 1-week projects. You want to have small, frequent plans.

Let's take a sports analogy. If you found out a football coach was trying to plan out every single play for the whole game during the first quarter, you'd laugh yourself off the bleachers. There's too many contingencies to account for. Instead, you want a coach that's going to break their planning down. Each play is a new project. Each project is planned quickly, executed quickly, and learned from...quickly.

So, this sprint-based planning is intuitively better. Let's work with a more real, software world example.

Let's say you're responsible for a system so that your company's users can coordinate their Secret Santa gift giving. You'd have your requirements:

• A user should be able to sign up
• A user should be able to log in
• A user should be able to get a recipient assigned
• A user should be able to add notes to their recipient

Now, since Amazon.com is super cool, and lots of people buying their gifts do so online, so you definitely need Amazon integration.

• There should be an "Add Amazon product" link that searches to Amazon
• There should be a "Buy on Amazon" button

OK, so we're good on the requirements. So, let's play this out through two scenarios. The first is a regular, waterfall-based project. The second, is Agile.

Waterfall

You go to your dev team, and find out that they think the sign up and log in features will take 3 days, the recipient selection/notes feature will take 2 days, and the Amazon stuff will take 4 days. 9 days of development time. Not bad. That's just under two weeks. So, you let them have at it.

One of the devs starts working on the sign up process, and the other starts looking into the Amazon APIs, for the integration. They go back and forth a bit, each working on their parts, the Amazon researcher adding information to the docs, then doing some coding on that part of the project, and 9 days later, they are miraculously done on schedule.

You being the proud project manager, you put it out there. Sally in Accounting notices that the Amazon integration doesn't always work right when she presses enter on the text field, so there's a day of debugging that. OK, 10 days. Not great, there's about an 11% overrun on days, but not bad either. All is well.

Agile

You go to your dev team. You decide that the sign up and log in functionality is essential to the project, so that gets implemented. This takes 3 days. Your Agile dev team deploys the code so that you can verify the features. Sign up and log in both work. Awesome.

The dev team continues. They add the recipient selection feature, which takes a day, and then the notes feature, which also takes a day. Of course, they've deployed the entire project for your verification after each of these steps.

Since you started on Monday, and it's been 5 days, that makes today Friday. That's perfect! Next week, finish up the integration with Amazon, and you're done.

Since your dev team has done such a great job, and the code is out there and running, you decide to send an email to the management team at your company, showing the progress so far.

You come in on Monday, and find an email from the company president in your Inbox.

"Hey, great job on the Secret Santa project. I love the notes feature, I've been able to search Amazon for gift ideas and just paste the URLs into the notes section for my recipient. Everyone else has been using the product already, and is really impressed. Great job!"

Wait, what? We had a spec document and haven't even implemented all the features. The project isn't even done!

Oh yes it is. Tell your devs to stop working. It's 100% usable, because your requirements changed. The project is done, you adapted to the change, and you got it done in 5 out of the 9 days. That's a 44% *underrun* in time. Go ahead and give that extra 44% back to the accounting department, and enjoy the shocked look on their faces.

This might not have been a real project, but it does demonstrate how adapting to change can benefit you. It also demonstrates the advantage of frequent releases of working software. The best way to know what you need is to have a semi-working version that you can test. As a friend says, "I know I'm wrong. I don't know how I'm wrong, but I know I'm wrong. So, I try something quick, and see what I need to change." True.