What in the World Is Wagile Software Development?
Just looking at the term wagile it seems as if this word is a combination of a waterfall development methodology and an agile development methodology; but, that’s not the case. Apparently, this word is a result of what occurs when a team slips from agile development into waterfall development. Here is the definition of wagile as found on Wikipedia:
Wagile software development is 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.
A blogger on rallydev.com explains how Telstra, an Australian company, transitioned several wagile groups into seven functioning agile teams. But is this the norm? What happens when your team slips back into waterfall after starting out agile? Does this happen frequently?
Let's look at how a team moves from waterfall to agile. It would seem more plausible for team members to slide back into waterfall methodology if the implementation were going poorly. In other words, they are returning to their comfort zone.
For that let’s turn to scrumalliance.org as the organization highlights how a federal government project went from waterfall to agile successfully. The article takes an in-depth look at the personnel, cultural, and organizational changes that had to take place. The piece also describes the lessons learned and what would have made the journey easier.
But what happens when a team reverts back to waterfall, as was the case with United Kingdom’s Universal Credit welfare system discussed in Jonathan Vanian's TechWell story? Since this story was published, it seems the system is still not working properly, as witnessed by this article on the Huffington Post on February 4, 2014. It seems that the organization’s slip into wagile has proven to be disastrous.
So, how do you know you are wagile? For that answer I turn to blueprintsys.com's list of ten signs you might be wagile. Another article points out why we tend to slip back into waterfall methodology, and the piece squarely places the blame on managers and their need to prepare and plan.
To learn how to keep the agile train moving, visit medium.com for one agilist's approach to staying on track. Strangely, the author puts planning and estimating as the top priorities after the prior article gave this as a reason as to why teams slip back into waterfall.
In closing, I’d like to know if you have had this issue? Have any of your projects reverted back to waterfall after trying to be more agile? Are you becoming wagile?
