Do I use Agile or Waterfall methodology for my IT project?

Information technology projects (aka “projects with computers”) are inherently different from construction and manufacturing projects.  In construction, if someone decides to add another floor to a building, it’s potentially a large change depending on progress.  When it comes to software, adding another “floor” could be just a matter of copy and paste.  IT projects rely a lot on experience for estimating and frequent communication.  For example, if someone was “virtually” building a 10 floor building for a video game, just being aware early on that the number of floors may change allows the developer to be prepared for that change, and develop the software to make that a flexible/changeable number.

There are various approaches, but let’s talk about two:

Waterfall

Waterfall implies all the steps of the project flow down follow concrete steps.  People approach and bundle these steps with different names, but according to the software development life-cycle:

  1. Requirements and Analysis – determine what is needed from the final implementation
  2. Design – determine how it will be implemented
  3. Implementation – build the solution that satisfies the requirements and follows the design
  4. Testing – test that the built solution matches the requirements and design

Pros

  • Customer has defined what they want and that is what is built.
  • Stages in the project are clear, and you cannot proceed to the next stage until you’re finished the current stage
  • If a consultant or contractor is engaged for the project, they can make a reasonable profit by only building what is expected.

Cons

  • Change is complicated and could add additional cost
  • Determining requirements is difficult
  • Seeing the solution could be a surprise and not what was expected

Agile

  1. A backlog of features/functionality is described in clear, concise user stories.
  2. Features from the backlog are worked on in sprints (short periods of time e.g. one month) and presented at the end of a sprint
  3. Customer gets to review the implementation enabling them to revise the stories and prioritize the stories for the next sprint
  4. This repeats until the solution is deemed acceptable.

Pros

  • Much less documentation needs to be developed
  • Frequent communication and ability for change

Cons

  • Change could be continual with a lot of re-work
  • Potential for significant development of throw-away code because of undefined detailed requirements

This seems to be a fairly touchy subject for some people, and I prefer to be flexible.  I like having a clear set of requirements, and I like projects where the solution is iteratively developed.  It’s very possible to take the advantages from each methodology.

Fast, Good, Cheap – pick two

We’re constrained by the project management triangle of scope, time, and cost.

  • Scope and Time constraints – costs will go up to get the work (scope) done by a particular timeline
  • Scope and Cost constraints – time will not be available to get the work done
  • Time and Cost constraints – your scope of what you can produce will be limited

Apply this effectively

With waterfall, you specify the scope to the best of your ability and if that takes too long, you’re going to cut into your timelines and/or spend too much.  With agile, you’ll get the scope finally, but you may need more iterations (sprints) than expected which could cost more than anticipated.