To Agile or not to Agile?

Choosing a project management style that fits

I was teaching an IT project management class recently and had a student ask a question I hear all too often: “We’re using waterfall right now but I really want to move towards agile, will we learn about that?” The answer is always, yes, we will cover agile. But the answer to “Should we use an agile style of project management?” is much more complex.

Eric Ries, author of The Lean Startup, seems to have inadvertently started a craze here in the Bay Area. It’s understandable. With so many software companies around here, terms like “iterative” and “minimum viable product” (MVP) have become ubiquitous (and sometimes nauseating). And certainly many software development projects will benefit from an iterative approach. But if you’re just creating an in-house app calculate payroll deductions or event registrations, waterfall is perfect. On the other hand, if you’re trying to develop a consumer-facing game in a fast-moving mobile market, agile is probably better.

Where it’s at: Requirements

The heart of the issue is how much you actually know about where you’re trying to go. Waterfall, agile, traditional, really any style of project management is only useful if you know the state of requirements. If the requirements are generally well-known and agreed upon (e.g. “The software must be able to calculate payroll deductions based on current state requirements.”), then a waterfall approach works great. A waterfall software development life cycle (SDLC) looks like this:

Because requirements are known, the progression through each project phase is linear. Customers, internal or external, should not expect to have much input once the project is running and should generally be satisfied with the outcome. But what if we’re designing a mobile game where the requirements are less understood? Perhaps we know it will be a first-person shooter involving wizards and aliens and that’s about it. An iterative process that allows us to test our game in the market for feedback is more useful if we want to ultimately make something people will buy. This is why agile is so popular. Work is done in short bursts or “sprints” that allow instant feedback to developers. An agile SDLC looks like this:

The idea is that the customer can give feedback throughout the process, possibly sending the project back to a preceding phase for rework. Though you and the customer don’t always know where you’re going, the hope with agile is that you’ll know when you’re there.

So which one is best?

There is no definitive answer here. That requirements be known and understood is the standard answer but “known” and “understood” are clearly subjective. There are many other variables to consider too, including how finicky your customer is. In any case be sure to do your best to clarify requirements before committing to any particular style of project management. A good project manager assesses requirements first, then picks the management model the is best for the project, not whatever style seems sexiest in Silicon Valley.

‍