The Leap from Waterfall to Agile – Breaking My "Good" (Bad) Habits

In the first 18 years or so of my career, I focused mainly on project initiatives following a Waterfall approach and methodology.  As a project manager running large initiatives, my success hinged on several key themes:  implementing structure/discipline, detailed planning (short- and longer-term), multi-year roadmaps with interim milestones, comprehensive documentation, change control, formal sign-offs, etc.  In short, these were the practices that guided my work, and they became second nature as I moved from project to project.

Then came an opportunity to undertake an Agile project.  I thought to myself: “Sure, why not?  I’m a flexible guy, and I want to expand my horizons.”  While I had heard whispers of Agile becoming more mainstream, the opportunity to adopt it hadn’t presented itself on earlier projects.

I was provided a few days of formal Agile training, and then came the proverbial “smack” across my face.  “Ken, we need you to be more nimble, less rigid, and focus more on the next increment/sprint than the next few years.  Less documentation.”  But what about the detailed requirements we need to draft?  The formal sign-offs?  Locking down scope before any software development commences?  I felt a rise in anxiety, as I was being asked to put aside all the skills and habits I learned from Waterfall projects.  My Agile instructor sat me down after class, and gave me some advice:  “Agile requires a new way of thinking.  You need to learn to break your old habits.  They work well for Waterfall, but badly for Agile.”  I feared that I might be an old dog who couldn’t learn new tricks, but I resolved to redefine my definition of a “good” habit.

Slowly, I adjusted to my new environment.  Smaller iterations combining business requirements, development, and testing replaced longer and individualized stages.  Reduced documentation, unstructured daily scrum meetings, flexibility replacing rigidity—all in the spirit of faster deliveries to production with an eye towards evolving requirements.  I now had another methodology which I could add to my toolbox.

As I undertook more Agile projects, complexities grew with interdependencies, requirements, and communication requiring a higher level of coordination and understanding.  I started to reflect back on how I employed methodologies in the first place.  They are a framework to put in place before embarking on a project journey, but, ultimately, their application is part science and part art.  The project manager has to customize the right methodology for the right situation.  On these increasingly complex projects, I realized that I needed a blend of Waterfall and Agile techniques—something like a “Wagile” approach!

Yes, “Wagile” seemed to make sense.  I could adopt Agile techniques for specific project activities, and Waterfall activities in other areas.  For example, discrete functionality and reports could be developed using Agile, with overarching program planning, architecture, and integration testing following a more traditional Waterfall approach.

I then thought back to all the Waterfall projects I had done, and recalled pockets where some Agile thinking could have benefited the project.  Back then, I believed we locked ourselves into thinking we had to choose one particular methodology and go with it.  This thinking was rigid, just like the methodology we were trying to employ.  We never discussed undertaking a more hybrid “Wagile” approach.  Now that my toolbox has more options, I plan to consider all methodology options when tasked with project planning.

In summary, the “leap from Waterfall to Agile” doesn’t have to be binary, and practitioners don’t need to leave behind old thinking (habits) and adopt a new mindset.  I consider it a journey where I explore new ideas, gain new insights, and learn new techniques.  In a prior blog entitled Project Management Tools – What’s Your Flavor, I wrote about the different options available to project managers in selecting tools to fit your project requirements.  In this case, I extend “tools” to include “methodologies,” and recognize that many flavors exist.  Sometimes, a project calls for either vanilla or chocolate.  And at other times, the mocha blend works best.