Remember when Waterfall was the software development methodology du jour? Nearly everybody managed the software development process by conforming to the linear, sequential style of the Waterfall.
But that’s no longer true. The Waterfall has begun to run dry. And yet, I find many IT departments are still stuck using Waterfall methodologies for tasks like change management or IT project implementations. While most software development shops have moved on to Agile, most IT departments are still in a Waterfall rut. Why? Perhaps it’s because of the general perception that Agile is just for software development. Or maybe it’s simply resistance to change.
Tweet this: Why some IT departments are stuck in the IT waterfall rut and 5 reasons to implement agile ITSM
If your organization still deploys the Waterfall methodology, you’re a member of a rapidly dwindling group. As you likely know, Agile has become the new norm in software development. And, the old Waterfall model is sporting quite a tarnished reputation these days.
Agile has exploded in popularity because it provides some very significant advantages over the Waterfall methodology. Agile can help to:
- Increase revenue
- Speed time-to-market
- Enhance quality
- Reduce risk
- Boost customer satisfaction
Done right, Agile offers all of these benefits, and many more.
Agile Is For IT Folks, Too
Some people think of Agile as a methodology that is strictly applicable to software development. But that’s simply not true. IT departments can also benefit by adopting Agile methodologies.
Whether your IT department is facing a large project, like rolling out Microsoft Office in the Cloud, or just addressing routine change management tasks, Agile can help.
IT operations can benefit from a move to Agile. And IT departments that are forward thinking, already doing things in a very structured manner, and/or have already embraced IT service management (ITSM) or the principles of the IT Infrastructure Library (ITIL) are particularly strong candidates for making the move to Agile.
There’s just that one little catch to worry about.
If You’re Going to Do Agile, You’d Better Do It Right
Yes, Agile offers quite an array of wonderful benefits that can make a significant impact on how your team functions. It wouldn’t be out of the ordinary, for example, for a department that normally completes just two or three projects a year to soar to a project completion rate of 10 to 15 per year. Agile offers that kind of potential.
So what’s the catch? Implementing Agile can have a high failure rate.
The problem isn’t because of inherent flaws in the Agile methodology. Most often, I’ve seen problems occur because of the approach an organization takes in implementing Agile.
Most often, there’s a failure to achieve buy-in across the organization. A lack of commitment frequently results in an organization throwing in the towel before they’ve fully implemented Agile. Any speed bumps in the transition to Agile are then likely to send frustration levels soaring, followed shortly by a return to the old ways of doing things.
The lack of buy-in is often related to a resistance to change that’s just human nature. “But that’s the way we’ve always done that,” is a refrain you might hear echoing through the halls of an enterprise making the move to Agile.
On the other hand, sometimes a company is completely committed to Agile, but just doesn’t have the right tool set in order to implement.
Tweet this: Going agile has perks, but also a high failure rate upon implementation. Tips on how to do agile right the first time
Are You Trying to Drive a Nail with a Screwdriver?
Ensuring that your team has the right tools is critically important. The tools your team uses should support Agile methodologies, otherwise they will only serve to work against your goals.
But IT departments frequently encounter a problem: While there are many Agile-compatible software tools available for development, there are few Agile-compatible tools available for IT. In fact, IT tools that were built from the ground up with Agile in mind are nearly non-existent.
Many organizations attempt to adapt development tools to the IT world as a workaround. If you’re a software development company, you might be able to make that work. But otherwise, attempting to re-purpose development tools is an approach that nearly always fails.
I’ve also seen teams attempt to add an ad-hoc or packaged Agile module onto an existing ITSM tool. But this approach also has a high failure rate. It’s kind of like bolting a jet engine onto a pickup truck. (It’s been tried. It didn’t go well!) Adding an Agile module to an existing tool may be technically feasible, but even in the best-case scenario it probably won’t do much good.
And, adding insult to injury, those ITSM add-on modules are typically quite expensive.
What to Look for in an Agile-Compatible ITSM Tool
The better approach is to deploy an ITSM tool that provides the inherent flexibility required to make it compatible with Agile. You want your ITSM tool to work with you, not against you. By deploying a tool that is configurable and customizable to your needs, you better equip your team to be Agile.
It’s also important to select a tool that allows you to ease into Agile at a comfortable pace. You can buy ITSM tools that are designed for Agile, but they usually require that you instantly become fully Agile-compliant. Those tools are counterproductive to organizations that aren’t ready to make the change at a breakneck pace. If the tool you’re evaluating prioritizes a quick Agile timeline that supersedes your department’s capabilities, tap the brakes.
And it’s easy to break the bank by buying ITSM add-on tools for Agile compatibility. Look for an ITSM tool that offers the flexibility of Agile compatibility at no extra cost.
You didn’t know that such tools exist? Good thing you read this post.
How will better agility help your business grow? Learn more about what your IT department can accomplish in our eBook, 3 Ways to Boost IT Agility.