Forget Waterfall, Understand The Basics

In the software development world, the term “Waterfall” has the same connotation as “green, oozing slime”.  Unfortunately, there is good reason for this.

Having come out of the Engineering/Manufacturing world, I am fully versed in executing projects in the classic, pre-planned environment.  There are any number of reasons why projects need to be done in this way (the subject for another discussion at a later date) and it is difficult to do software development in this environment.  However, with good planning and management, it can be done (I have proven that).  Part of the reason that we can be successful in developing software in this environment is that the requirements are well thought out and documented at the beginning because the customer environment is well understood and definable.  At the same time, the hardware aspect of the projects are typically larger than the software and much less subject to change.  This gives the entire project a different flavor than software only projects.  This is the same issue that is presented when you have a project where there is a significant hardware component (typically seen in embedded applications).

But, getting back to my original thought, I think that one thing that we need to understand is that that classic, pre-planned approach to projects (i.e., Waterfall) is not a requirement, merely the most common approach to Project Management.  At the same time, we it is completely feasible to take the concepts of Project Management and, if we understand them, apply them to Agile Project Management.  It’s all the same thing, just a different set of priorities and processes.

Take for example the fact that every project has requirements (functional specs, user stories, use cases, whatever) and costs and schedules / deadlines.  The only significant difference between classic and agile projects is that these are prioritized differently.  The processes in the agile world are designed to deal with a highly volatile set of requirements.  The classic world assumes that the requirements are significantly less volatile while adherence to cost and schedule are critical.

For a great, in-depth look at this issue and to learn more about the relationships between the classic and agile Project Management worlds, see Michele Sliger’s book “The Software Project Manager’s Bridge to Agility” (you will find it at Michele’s website: Sliger Consulting.  I highly recommend it.