Blog Post

Waterfalling into Agile

Published on

Feb 18

Linda Hollingsworth

Suggested Articles

Project Management was once called the ‘accidental profession’ because of the way in which many Project Managers obtained their skills and title. Now Project Managers have professional training and certification programs to facilitate the delivery of projects across industries that maintain a consistency of quality. Change is afoot in the field of project management. Change is inevitable in anything we do!

Waterfall Method

For years, the recommended methodology for attempting to deliver projects on time, on budget and within scope has been a sequential, well-documented and organized method called ‘waterfall’ or predictive methodology. It derived its name from the stair-step, waterfall approach and philosophy to completing each phase of a project (i.e. Discovery, Design, Develop, or Test), before moving on to the next sequential phase. When product options are few or can be clearly defined, this method can work well. Even predictably. However, change or the unknown is waterfall’s nemesis. Depending upon how far over the waterfall’s edge of product development you have jumped, waterfall does not allow for change to the established requirements without significant planning, documentation, rework, testing, time and cost.

Changing to be Agile  

In the 1990’s the software development community began to embrace the lean, just-in-time concepts being practiced in manufacturing, forming new project management methodologies. These became known collectively as agile software development methods, picking up on a term coined in the 2001 publication of the Manifesto for Agile Software Development. Some of the Agile methodologies include Scrum, Lean, Kanban, RAD, XP, etc. They all espouse an iterative and incremental approach to development based upon the client’s/product owner’s priorities.

Agile methods emphasize a few essential principles:

  • Planning is useful, but blindly following a plan is like walking off a cliff… or waterfall, as the case may be. Plan reality, not fantasy. Develop estimates based on the relative complexity of tasks, combined with team velocity for completing work.
  • Constantly inspect and adapt your design. Don’t guess! Plan, Do, Check, Act and Repeat. Fail fast so that you can fix early. Focus on the 20% of functionality that yields 80% of the benefit.
  • Build cross-functional, empowered teams that collaborate and establish a rhythm throughout the project to deliver incremental product enhancements. Small wins over explosive successes. Focused, transparent daily communication over mounds of paperwork and inefficient protocol.

Waterfall methodology is still alive and kicking in the Project Management world where large teams strive to move the battleship of their large projects. However, in our increasingly cloud-based world of applications and/or iterative release of product functionality, we find the speedboats of Agile methodology stirring up the water, zooming around and through the waterfalls of slower delivery methods. In his book Scrum, The Art of Doing Twice the Work in Half the Time, Jeff Sutherland, Co-creator of Scrum and Co-author of the Manifestor for Agile Software Development, says it this way: “Change or Die. Clinging to the old way of doing things, of command and control and rigid predictability, will bring only failure. In the meantime, the competition that is willing to change will leave you in the dust.”

Written By