Agile Development

I am interested to see if people have been using the Agile development and their view on the Agile versus Waterfall approach.

One of the key principles of the Agile development is to "welcome changing requirements even late in development". I am still trying to understand how such an approach (agile) or any other approahes can overcome the impact on changing requirements on the project scope, timeframe, and cost? Also what are the techniques that you can utilise to reduce such an impact?

I am okay with all the other principles and support them:
1. Early & continuous delivery of software components (big tick)
2. Business people and developers must work together daily throughout the project (big tick)
3. Face-to-face conversation (big tick)
4. The sponsors, developers, and users should be able to maintain a constant pace indefinitely (big tick)
and the rest....

Any view is appreciated...

[JohnnyBgood]

Hi,

I have had a little bit of experience with agile development in business intelligence. The main impact on delivering business intelligence within this sort of development environment is that you don't have a hard and fast set of business requirements upon which to base, for instance, your new report design.

In the normal waterfall model the presentation layer is built with a set of signed off and detailed business requirements. In the agile world you are often working off a much less specific design criteria. The result is that in the agile world I have found that building the presentation layer must be in a closer partnership with the owners of the future reports, dashboards, etc.

So my experience with the agile approach has proved to be a very effective one. This is because agile forces you into very close partnerships with the end user and despite having less clear business requirements to start with, the end result is a much closer representation of what the user wants but it still has all the benefits associated with being designed by a business intelligence professional.

So it is a bit of a counterintuitive result but I am all for it.

On the down side I don't think that this is the thing you can enter into half-heartedly. For example if you are going to go agile, then you don't have to go 100%. This means that you can't just to it for the presentation layer but you also need to have it right back into the ETL. If you don't do this then your agile presentation layer team will be forever waiting for the new data requirements to be delivered through the ETL, data warehouse, and data mart layers.

Hope that helps! I would also be interested in hearing from other people of their experiences.

John

[binboy]

I cant help you with any of my own experience, however, are you aware of this site dedicated to Agile development process - there are many articles & Q & A's that you may find helpful

rgds

http://www.agilealliance.com/

[admin]

I have just joined another online community of BI Consultants. That led me to the following blog entry talking about agility in BI projects.

I agree with John's earlier post: agility is generally a good thing. My only additional observation is that going agile places more importance on being highly organised and methodical - even more than when following a more traditional waterfall approach. Why? Because the decision making cycle is more compressed and the impact of any errors or omissions rapidly ripples through resulting work. All of which becomes potential rework when the error is picked-up.

John Mayers

[Doug Heywood]

I use wiki's to store knowledge about the agile project so that the knowledge is captured fast and is instantly available to all involved in the project. It's free software and web-based so it's easy to get up and running.

I also just made a post in another forum with an interesting case study using a modeling tool in an innovative way. Check it out here.