I just finished reading a blog by Michael Fitzgerald, CIO Tough Love: Agility Demands Increasing. In his recap of the 10th annual MIT Sloan CIO Symposium, Michael rightfully warns IT Executives to “brace yourself for pain as you push for agility”. I couldn’t agree more. And, the pain comes from many directions and takes on many forms, but there are proven tools and techniques to help you along the way.
The initial onset of pain happens when it becomes obvious that the IT organization is not equipped to support the increased tempo of decision making and “turn on a dime” agility that today’s business requires. The business climate is changing much faster than IT was originally designed to keep up with. Organizations have taken decades to evolve their infrastructure to where it is today and now must change rapidly to keep pace with the step change in competition that the business is facing.
There’s even more pain when you begin to apply agile development methods and realize that your current technology stack can’t support a more rapid way of implementing. Much of your data is locked in legacy applications or monolithic ERP systems that are designed to enforce repeatability and consistency, not agility and adaptability. A different mindset (and infrastructure) is needed to address the new reality of today’s economy.
Another agonizing pain point shows up when you get the push-back from the people within your very own IT department as you try to change life-long habits and years of training on gated, waterfall methodologies. Imagine the sentiment as you begin your journey toward agility when discussing it with your existing IT leadership. It can be extremely difficult when you are starting the conversation with something akin to “you’re doing it wrong”. Cultural change like this doesn’t happen overnight (though when your desire is to become more agile, you hope that it will). A major shift such as this requires a programmatic approach to continuous improvement and perhaps a change agent with a high tolerance for pain to bring the organization along. It also means that you must measure success and productivity differently.
But, I think the most painful aspect is when the realization strikes that you can’t just apply agile to one part of the process and expect it to produce the results you need. The production of better business decisions is the outcome of very complex processes – business and data processes taken together. In order for this end-to-end process to perform optimally all events must perform optimally. The process interdependencies require the entire extended “data supply chain” be taken into consideration when determining how and where it is best to instill agile methods. Otherwise the wait times between events will slow the process down. As an example, implementing specific tools to enable agile BI leading to a higher degree of business user self-service seems like a great idea to get data into a decision maker’s hands more quickly. However, if you haven’t also adopted more rapid data integration practices, then your demand will still outpace your supply.
This piece isn’t meant to throw a wet blanket on the idea of agility. I am all for it and advocate that agile approaches (integrating methodology and software-driven automation) are the only way to improve IT’s ability to support the increasing cadence of decision making that the business demands. I do, however, want to set some realistic expectations that there is no silver bullet for becoming agile. There is no switch to make everything better. Becoming more agile takes determination, persistence, steady progress, and with the proper application of tools along the way you will be able to support many small wins as you journey toward becoming a highly productive agile enterprise.