Rotate

Please rotate your device.

Our website uses cookies to ensure you get the best experience while you’re here.

Swirl

Agile Series, Part I: Does an All-Agile Approach Make Sense?

By: SEI Team

agile-series1

I remember when I first heard about Agile techniques in business and read an article in the Harvard Business Review titled, Why Good Projects Fail Anyway.  Agile wasn’t even mentioned, but the idea of “rapid results” project management gave me a new perspective on how to approach large IT initiatives.

I became a believer in the basic tenets of Agile – short term planning, iterative and incremental development, focused accountability and fast-succeed/fast-fail results. It made sense then, and it makes sense today. Or does it?

All-Agile All-the-Time?

At a recent client, I had a discussion with a CIO about the All-Agile, All-the-Time approach they were taking. The thought was to have all corporate IT initiatives be managed as Agile projects, with scrum masters, product backlogs, sprints and PODs. It made sense to us. That is, until it didn’t.

Can a company embrace Agile as the be-all and end-all of project management? I think the answer to that may sound familiar to many of us in consulting – it depends. That CIO had seen less-than-stellar results at other companies that tried a big bang approach to an all-Agile shop. So had I. It can be a mess.

Trying to go all-Agile can pose serious risks to an organization, such as shortfalls in human capabilities, productivity threats, resistance to change, and lack of leadership commitment. The benefits of Agile must be weighed against the risks and, I’ve found, a measured approach is best.

Agile: Not the Only Answer

Some projects lend themselves more to Waterfall. Or Lean/Kanban. Or even Lean Agile. While it may make sense to set up a primarily Agile shop, having the flexibility to support a more conservative approach to a potential few projects that don’t fit the Agile mold, may be the difference between success and failure for the delivery function at a client. Going Agile takes time too, so transitioning in phases is usually the best way to roll it out. In the end, I try to think of it as in terms of the business case for Agile, with a little dose of common sense. What makes the most sense for the situation, the business, the customer and the CFO? I like Agile as much as the next guy, but I like value even more. And in the end, that’s what matters, delivering value to your customers.

Check back in next week for Part II of the Agile Series to learn what to do when your large client is ingrained and institutionalized in Waterfall methodologies, and you’re forced to utilize Waterfall on your project but could benefit from some Agile principles.