Why Agile instead of Waterfall?

When I was an undergrad at Carnegie Mellon getting a degree in Information and Decision Systems back in the late 1990s/early 2000s, we were taught the waterfall software development model as the gold standard for how to build software.  

Eager to put my degree to work, I got a job at a company that built software for state and local governments.  I soon found myself on a project working to implement a new HR & finance system for a state Department of Transportation.

Waterfall focuses first on a period of “discovery” where you spend hours with your client or stakeholder so they can tell you EVERYTHING that they needed the system to do.  It was then my job, as a business analyst, to diligently document this in the form of workflow diagrams and large requirements documents.

Once the requirements document was signed off, the project manager sat down in a conference room with the tech lead, opened up a new Microsoft project template, and begin to document, step by step everything that needed to be built - linking each resource from one task to the next in a beautiful cascading Gantt chart resulting in a clear end date and resource set!

This could be delivered to the client as a budget and timeline and the project would be off and running!

It was very straightforward and always provided an answer to how long and how much.

The problem was . . . it was always, always, always wrong.

And it was wrong for so many reasons - someone got sick or left the company, something was harder than we thought, chunks of work that needed to be done were missing, business assumptions weren’t correctly understood,  the business needs shifted, etc. 

And then the project manager had the joyous task of every day asking everyone working on the project “Are you on track?” and then duly updating the project plan with all of the tasks that were not on track and coming up with a new plan.  Just keeping the project plan up to date was a full time job!

Once a month the project manager would update the clients as to how the launch date had shifted and the budget had expanded - because the launch date ALWAYS shifted out and the budget ALWAYS expanded.  And the client would huff and puff and there would be some negotiation over budget, but ultimately they’d agree, because the software needed to be built and there was no other choice.

But the real kicker was that after all of this time of being over budget and delivery dates sliding, when the project was finally delivered to the client for user acceptance testing acceptance it wasn’t what they really needed!

And then would come another round of huffing and puffing and budget negotiation and change 

orders just to try to get the software into something that was usable.

I went through this process at several companies - sometimes it was for internal stakeholders and sometimes it was for clients, but the end result was always the same - somewhat usable software that was expensive and delivered late.

There had to be a better way.  And there is . . . agile.

In later posts I’ll get into the Agile principles, but in my own terms, I think of it as:

• We are bad at describing what we want.

• We are bad at understanding what people say they want.

• But we are very good at reacting to something we see.

So instead of spending a lot of time talking about what the clients and stakeholders want and what we’re going to build, we’re better off understanding where we can deliver the highest business value, building a little of it (ideally in lightweight prototypes to start), showing it to our stakeholders/clients, getting their feedback, and working from there.

Once I started working in an Agile mindset, I found that I could deliver higher quality software that better met the business need faster and I’ve never looked back.