I obviously cannot share details here in this blog format regarding things like the decision frameworks. Gartner clients who are interested in this topic should arrange to talk to my colleague David Norton and read his research on this topic. Others are advised to work with internal or external consultants and gurus with regards to formulating policies and guidelines on picking the right methods and approaches for individual projects and initiatives.

First, it should be noted that Agile methods need not be applied to a solution being built for only one business unit. Ideally, within the iterative timebox you can involve as many of the pertinent business analysts from ohter business units as possible in order to design the solution with some degree of intelligence in a way which is likely to meet the needs of more than just the primary/first user.

Second, iin an ideal world you have a business process center of excellence where the business analysts have been collaborating on the potential reuse of processes, steps, tasks and data on an ongoing basis as part of the Future Solution Architecture (FSA). Even if the IT project is of limited time and scope for implementing a given process, you should have with the FSA some reasonable vision of what reuse needs to be designed into the solution for future processes or iterations (and whcih business analysts ought to be consulted on the project beyond the primary business unit).

Again, the methodological approach to a project needs to factor in a lot of things – and there are times when Agile will be appropriate and other times when a more formal approach makes sense. This requires both IT and the business to make good choices based on the short-term business opportunity and ROI, but also other factors including quality, maintainability/agility, compliancy, security, consistency and total cost of ownership.

And, now, I will be heading out for a week of vacation. So, I urge you and others to please be patient while I take some time off.

I agree with your comments

The main issue that you’ve stated is that the cost of development using Agile means is offset by the early financial benefits that business would derive.

One question I have is whether adopting an iterative approach will be feasible in large implementations involving multiple business units having multi site operations. While everyone would like to have early benefits, is the approach risky for the organisation. For example, in a Steel Industry environment that I work in, I could start with a Supply Chain Project in one of the busines units (say Flat Products) and then later on iterate the same design for Long Products. However, in this approach I may be taking the risk of developing a design that is not suitable for the second business unit

On the contrary, an integrated approach would be less riskier, albeit more time consuming and costly.

We need to make Agile methods the norm as no one can afford large implementation time frames. Proper standards and well proven methodologies are the need of the hour

And I encourage proactive things which can expedite solutions as described in my post on “Master Data Management Enables BPM and SOA” as well as implementing the role of the Application/Solution Architect to create reusable software and data services, patterns and templates across application solutions to improve quality, productivity and consistency.

But I’d also like to address two positive things about Agile methods:

1)Agile methods are iterative and intended to build more agile solutions – so overheads ought to be more easily addressed in later iterations and

2)The business can derive value from the delivery of early iterations.

So, while the total cost of development and maintenance of a set of solutions and iterations built using Agile methods might be high, this can be offset by producing greater financial and competitive advantages to the business sooner.

Also, I would like to point out there are advantages to using Agile methods for doing business process improvement – beyond those benefits which IT may see using Agile methods for developers.

But to substantiate your point, organizations need to look at each application or service solution and determine if Agile methods are appropriate or not based on sound business principles.

This is a very pertnent subject and is bothering me also. I have been wonedring how to develop IT Systems that “change at the speed of business”. This is more relevant in the current economic downturn scenario wherein the demand for IT has not really slowed down and business users are asking more and more changes to adapt to new situations.

There are two aspects – How to
1. Develop new IT systems using Agile Methods
2. Change existing IT Systems very fast

The former requires adoption of new methodologies that focus on only few critical aspects of development and leave the overheads to be completed at the end.
The latter requires a solid architecture that is flexible to change, For example – a Master data management foundation which allows building of flexible IT systems