How Agile is Your Organization?

By Jim Strebler
Senior Consultant

There is a new (well, not so new) methodology being used in IT to develop applications called “agile.” Agile promises to deliver usable applications quicker and exactly the way the users need them. It has been around for more than 15 years and now seems to be gaining acceptance as a valid approach to IT development.

I learned about agile years ago, and there was something about it that I liked immediately: When business users needed something changed in a project, the developer made the changes. No muss, no fuss; the change got made—without a lot of time or effort spent documenting the change request, getting multiple approvals, and revising the project timeline. It all might sound like a recipe for catastrophe, but agile has its own set of rules and processes that keep things under control. Without the bureaucracy, IT projects under agile are completed quicker and with higher satisfaction ratings from both the business users and the IT team.

The question I’ve worked on for a while is this: “Why can’t whole agile organizations operate in an agile way?” When a process or operating rule gets in the way of getting stuff done, shouldn’t it be as easy as just changing the process? Do we really need to touch base with multiple areas for input and get their approvals and sign-offs? And is it really the end of the world if a changed procedure needs to be changed again because something was overlooked or doesn’t work?

There are, of course, processes that fall outside the realm of what can be changed in an agile way. For example, controls under the Sarbanes-Oxley domain must be vetted and documented appropriately, and processes with the potential to negatively impact customers must be implemented with great care. Outside those types of things, plenty of processes can be changed easily and do not jeopardize the organization—such as the requirement that a supervisor sign off on an insignificant task, like making copies in a copy center.