One of the failings of the Agile manifesto and principles is that the “as is” state of practices and technologies is ignored. Therefore Agile DW practitioners are confronted with the problems of developing in an innovative way and conforming to what seem to be archaic rules of engagement with the corporate technology and software infrastructures. Agile is easy in an environment where there are no competing rules or dependencies. When faced with the complexities of infrastructure and data integration, Agile practitioners need to adapt.
So what can we do when architects tell us that we MUST do things that impact our ability to deliver business value?
First the operating environment. There are no agile technology products. Agile is a philosophy driven methodology and is therefore independent of technologies. However, the problem is there are many anti-agile practices entrenched in the corporate IT environment. These range from “Corporate Data Models” down to SOE operating environments that preclude Agile “dependence free” practices.
The issue is that all complex systems have dependencies. IT technologies are usually robust in, and of themselves but in combination are quite fragile.
For example, just because a corporate data model exists, it doesn’t necessarily follow that it reflects the real world state of corporate data. In fact that is usually not the case. Nor is any corporate data model truly reflective of business needs. That is because the business changes faster than the model. So it’s rather fanciful to demand that the real world should match the model rather than the opposite case.
It is also rather silly to expect a free reign development philosophy to work effectively in a multigenerational IT environment. The idea that small groups of developers can dispense with specialisation and build effective and efficient systems is folly.
For the agile movement to succeed in larger organisations, it needs to develop practices that meet the realistic needs of the IT organisation. The cost effectiveness of developing systems iteratively is well proven, but agile needs to adapt better to the real world where risk is defined as upsetting the status quo.
To the corporate world, agile is little more than a new way of prototyping that results in continuing beta releases. This would be a real problem were it true, it is not. However the perception that it is must be addressed. The recent troubles with a well-planned but flawed upgrade in one of our Australian Banks shows that errors occur no matter how good the planning.
Small targets (largely the current focus of Agile) are tactical and therefore reinforce the view that it is not a legitimate competitor for waterfall.
For agile to succeed in the corporate world, it needs to adapt to the reality of the multigenerational IT environment.
While we have spent a lot of time and effort resolving many of the Agile problems of dealing with real world data management and integration, we still encounter these attitudes. So our agile methodology is, like agile itself, is continually evolving as lessons learned are incorporated. We therefore have a competitive advantage in that we can cogently argue the case for agile – it costs less, and delivers more and better information sooner.
When we all can argue that approach convincingly, Agile will come of age.
For MIP it represents a competitive advantage, but only over competitive waterfall approaches to the same situation. We can and do use the knowledge we have gained and we do win many more clients than we lose. We do come up against the Architecture/Risk/SOW/CMMI/ITIL etc. arguments against Agile. But over time we have accumulated the counter arguments. In some cases the entrenched interests will insist we conform to “standard methodologies”. We do! We still deliver faster, though not as fast as we could, we still cost less and we still deliver higher quality, more functional systems – we just try not to focus on the frustrating inefficiencies.
Agile cannot succeed in isolation, so we need more IT people to take up the challenge and THINK.