A recent survey indicated that the gap between IT and Business is growing and that might signal a change in how enterprise technology is run. There are increasing reports of IT not meeting business needs. Does Agile address these issues - and if so where is the evidence?
itWorldCanada reported on a survey that there is a need for better communication and understanding between IT and Business:
...the future of the IT professional no longer lies in acting as an important support system or innovative visionary but as a “utility.” According to him [Michael O’Neil, Info-Tech Research Group research fellow and author of the survey] , as technology becomes more and more an integral part of the enterprise, the role where IT functions as a discrete, advisory body will disappear; those left behind, he said, will be the “bits and bytes types” who want to work with the nitty-gritty of IT (such as network admins or coders), while the majority of IT professionals are assimilated into areas pertaining to business processes and strategy.
This was inline with an article provocatively named Fire Your CIO? If he's not implementing strategy, show him the door. :
The “new CIO” needs to be both an executor and a strategist. He or she should understand business processes first, and the latest technologies second. By working with the CEO and other key executives, this CIO should quickly ascertain the key strategic priorities that the organization must tackle. The “new CIO” will then translate these strategic imperatives into a technology plan that rigorously focuses on return on investment, and on streamlining the business rather than implementing a particular system.
So - what does this have to do with Agile? There is a definite focus on the Customer and Business Value - at least in the rhetoric. But does Agile deliver when it comes to strategic priorities? As far as we can tell, it really depends on what you read.
The most common recommendations when it comes to Agile processes and practices are inward looking and at project level. The vanilla Agile methods are focused on project success and look to satisfy the customer that is part of the team. There are many inspect-and-adapt cycles, but they focus on project status and progress. Daily stand-up meetings, iteration demos and reviews, and retrospectives are all inward-facing practices and do not take external business value explicitly into consideration beyond having a Customer or Product Owner.
There are, however, some in the field who recommend looking at external business value - that is, what software projects have to offer to the business. In last week's Agile Measurement - A Missing Practice? we reported on different strengths and weaknesses of Agile methods concerning measurement. In Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value, we were told what makes a good measurement candidate. The paper was silent on whether these were outward facing metrics or inward. One of our readers commented:
I've been at this business just shy of 30 years and have yet to see a formal, published study any time after project completion to say the ROI that we projected was met or not. Is that the kind of measurement people are after? Anybody here do such studies regularly?
Also, series of articles have been written about how to incorporate and measure an organization's business value when considering Agile development in the Agile Journal December 2006, January 2007, and March 2007 issues. These articles vary from asking and answering "how do you know an Agile Project has succeeded?" to suggestions on aligning day-to-day activities with business imperatives, to bringing Lean, Agile, and Theory of Constraints together to target your particular environment's business needs. Liz Barnett wrote:
How do you know if an Agile project has succeeded? The typical response I get to that question is a blank stare or moment of silence, depending on whether the meeting is in person or by phone. And if I do get an answer, it's usually accompanied by a "we're just starting" comment. The challenge is twofold: development organizations are notoriously weak in collecting metrics and reporting on their projects and, when using Agile processes, many teams are challenged to demonstrate if the change from traditional approaches was worth it. As IT costs and business pressures escalate, it is critical that a development shop can demonstrate its value to the business.So - are we there yet? Probably not, but we are moving in the right direction. The questions are - does this solve the problems raised in IT organizations and the growing gap? Do these IT departments know about Agile development? Or have they tried it and failed to find the successes reported above? Is there more that the Agile community should be doing to explicitly address these issues?