Ask a room full of tech executives about their strategic plans and you’ll hear the “A” word more than a few times. The shift from waterfall to agile has been a talking point and priority for any organization going through transformation, when the need for speed is paramount. My organization is no exception. We have agile coaches embedded, and we’ve had successes with agile methodologies. But this isn’t an ode to agile: There’s enough of those out there. This is a reminder to take a step back from time to time and evaluate why you are doing agile in the first place.
[ Explain agile in an easy way: Read How to explain DevOps, agile, and automation like a golfer. ]
The ultimate goal of any organization is to produce quality results for its clients. Any process that inhibits or restricts the organization from delivering on that goal effectively should be identified and eliminated. Sticking with a process that’s holding you back is foolish – whether it’s waterfall or agile.
Die-hard agile fanatics will ask, “when is waterfall ever the better choice?” or insist that “agile everything” is the only path forward for the modern IT organization. But the truth is, there’s nothing wrong with any process if it succeeds in getting you to your goal effectively. The problem is in trying to force square pegs into round holes because of a religious belief in a specific way to do things.
A false goal
If “Are we 100-percent agile?” is more important than “Are we achieving the results we need?” you are missing the point completely.
In fact, 100-percent agile doesn’t align with the reality in most organizations. It’s rare for even small companies with just a handful of developers and project managers to do textbook-perfect agile all the time, where everyone is in the same scrum meetings and everything is working gloriously. You’ll more typically find a combination of agile and waterfall working in perfect harmony.
At Epsilon, we’ve gone through many acquisitions. We have some groups within our organization that do very traditional waterfall development, and it’s working well. There’s no need to rock the boat with these groups. We have other groups that strictly do agile development: It works for them, and they are getting the job done. But more than anything, the majority of our teams are adopting a hybrid approach – taking what’s working from the various philosophies and software development methodologies and creating their own pathways to success.
For example, we have some scenarios in which bigger, slower-moving solutions just work better with waterfall development. There is a need to have a clear line of sight into a longer roadmap for these initiatives. However, within these same project realms, there are pieces of applications or code that are run in an agile fashion. It helps us keep up with the demand for speed on those specific elements. It makes no difference to us that we aren’t married to one “right” approach: It only matters that we are being as effective as possible.
The path to quality and speed
At the end of the day, the “right” approach is whatever enables you to deliver the best quality product in the shortest amount of time possible.
If you find yourself or your peers getting hung up on methodology, take a look at the reliable, repeatable processes that are already working in your organization. Don’t rock the boat in the pursuit of 100-percent agile. You may do more harm than good.
[ Want to give your team a greater sense of urgency? Get our new resource: Fast Start Guide: Creating a sense of urgency, with John Kotter. ]
