Good and Bad Wagile

I’ve been reading a lot of articles lately about “Wagile”.  For those that don’t know what “Wagile” is, Wikipedia describes it as:

a group of software development methodologies that result from slipping from agile back into waterfall, doing a lot of short waterfalls and thinking it is agile, Waterfall model masquerading as Agile software development, etc.

Basically, it refers to adopting a few Agile practices, such as short iterations, the daily stand-up, or continuous integration, on top of a waterfall model, without significantly altering the waterfall model.  It’s also been called Waterfall-Agile and even “Wet Agile”. (warning - don’t google the latter at work.)  And from what I’ve been reading, “Wagile” is the scourge of the earth.  A plague upon software development.  Even, as Jason Gorman put it, “Wagile…is the pinnacle of dysfunctional development methodologies”.  Wow!  That’s some pretty bad stuff!

It has been my experience, however, that Wagile doesn’t have to be such an awful thing, especially when in the process of introducing and rolling out Agile.  Yes, Wagile can be demoralizing and catastrophic to an Agile adoption, as when a friend of mine explained the rollout at her large Telcom company. “They decided to crash the project I’m working on, so they said we’re going Agile.  Now, I have a deadline every two weeks and a 7:30 AM daily standup!” Obviously, this is not Agile, nor even well masqueraded Agile.  Perhaps good Project Management, but definitely not Agile.  This, I think, is the “Wagile” that drives Agile evangelists nuts!

I posit, however, that Wagile can be done well, and may even be a necessary part of Agile adoption.  The key difference between “good Wagile” and “bad Wagile” is making it part of a continuous improvement process.

When we started to roll out Agile here, we had to do it in baby steps. We had a candidate project and our old waterfall methodology (complete with a power-point slide of a circular arrow representing iterative development cycles). With no budget for formal training and Agile being too large a culture shift at the time, we cherry picked Agile concepts to integrate into our first pilot project.  Luckily we had a few strong leaders who self taught and a team that was willing to experiment with methods. It was hard for us all to envision this whole thing actually working in the real world, despite the glowing success stories out there. So, we chose easy concepts to implement.  We started with the two week iterations, daily scrums and co-location.  Requirements were still provided up front, and the stuff we planned into our iterations was technical-task level (e.g. write stored procs for x process – 1 day), QA was back-loaded on the project, and product owners were still on the other side of the building. The Project Manager (me) had weekly status meetings with the Product Owner. But it worked, and worked well. The tech team worked more cohesively. Calendars cleared up as the need for recurring meetings and emergency meetings were removed.  As a project manager, I could monitor the project through listening to the scrums and more effectively and proactively remove obstacles for the team. My status reports were reliable.  Problems were tackled early rather than allowed to fester. It wasn’t perfect, but it was indeed better. It was the lump of brown sugar you steal while making cookie dough. Sweet enough to make us want to try more, to add more elements of Agile, to keep trying.  Imagine how good the actual cookies could be!

Where I think some Agile adoptions fail, and Wagile is bad, is that they stop there. The improvements seen from just those steps were amazing!  Hooray, we did it!  Who needs cookies! Let’s just eat the whole bag of brown sugar!  But it’s a mistake. You just make yourself sick in the short run and crash in the longer term.  You can do so much more, so much better. After a time, some of the leaders of that group (sometimes the PM, sometimes an Architect) would introduce another new Agile concept.  Continuous integration.  User stories.  Story point estimation. Shared responsibility. And even…gasp… inviting the product owner into our coven, as part of the planning, decision making and scrums.  2 years later, we are running 100% of projects as Agile, and pretty close to the scrum frame work described by the Mike Cohn book we first read.  However, we would never have gotten there had we not walked through our own “Wagile” rollout stages.