When someone asked Gandhi what he thought of Western civilization, he replied, ironically, that he thought it would be a good idea. In the last few years, much attention has been paid to extending the concepts of agile software development to the IT department in general. Unfortunately, this attention has resulted in IT strategies that seem to bear only a tenuous relationship to agile development processes and practices. The good news is that by cutting away the undergrowth, the savvy CIO can indeed create a more agile IT organization—and that would be a very good idea.
Very simply, IT can be seen as having three tasks:
1. Running the business (i.e., the computing that keeps it from collapsing)
2. Providing services (not only giving support for end users, but also providing apps that carry out business tasks requested by corporate)
3. Creating new products.
Over the years, these tasks have become fuzzy. Lines of business may have their own computing arms to provide additional support for running the business and providing services. New product development may have its own developers. In mid-sized organizations, particularly, flying Scrum teams flit from Business Integration (BI) app to BI app, outside IT’s purview. Internally customized business-process apps may be just as important to business success as new software-involving development. And the boundary between IT and public clouds, outsourcers, and contract developers is constantly fluctuating. As a result, IT is typically not in full control of any of these three tasks.
In the last five-odd years, agile software development has been added to the mix in a sudden flood of alien processes. Whether it begins outside or inside IT, agile creates more urgent pressures to synchronize with the speed and constant changes of direction of the developers. What IT often fails to fully comprehend, however, is that agile is a process and a state of mind; it’s a culture shift. Agile is also no longer restricted to software development; marketers think agile and have agile processes, and so do business analysts performing agile BI. They talk the same language as developers, but not the same language as traditional IT. In fact, they don’t talk the same language as traditional corporate.
The model of an agile project is a series of “sprints” that begin and end with feedback—preferably from the ultimate customer of the company, but often indirectly via a company end user or surrogate. These constantly, incrementally add value the end user can employ immediately: incremental prototyping. In other words, the project doesn’t focus on delivering a product; it focuses on customer-driven product change.
Now let’s look at how agile IT can help. Run-the-business applications such as Enterprise Resource Planning (ERP) are constantly evolving by addition of apps “on top of them,” and these apps therefore have a “lifecycle” in which, ideally, agile developers and sysadmins bat upgrades and bugs back and forth. Agile sysadmins should plug into agile development organizations via the collaboration and project management tools agile developers are using. That’s agile sysadmin.
IT has traditionally been a passive, overwhelmed recipient of demands for services. Agile IT proactively targets organization needs—and the best agile IT targets the needs of the ultimate customer first, and then relates them to business needs.
IT has traditionally been starved for new-product development resources by the demands of keeping the business running and (to a lesser extent) providing services. Agile IT takes the location of new-software development as a given, and simply seeks to mesh its own agile development efforts with those outside. Agile product marketing can be a glue here; at the very least, they will have a better take on what customers want than corporate, which too often relies on selective opinion rather than reaching out via customer communities.
One strong caution: True agile IT has become confounded with concepts of lean/just-in-time, outsourcing “basic functions” or recasting them as automated services, and self-service management. While these are worthy aims, unless you create an agile process, they can actually embed fundamentally un-agile IT even deeper. Another caution: You are what you measure. Measure the progress of an agile effort by time to value rather than cost, revenue, and/or quality.
Why is this a good idea? Studies show that by focusing on change rather than cost, revenue, or risk, agile delivers 15 to 50 percent lower costs, greater revenues, lower downside risk, greater upside risk, and higher customer satisfaction than other approaches. These pluses apply to IT as well.
So what do I think of agile IT? I think true agile IT would be a very, very, very good idea.