Priya PatraDelivery Director| Capgemini India Technology Services LtdMumbai, India
Yesterday I was asked by a colleague on how to apply Agile practices to Data ware house projects ?
At the First thought.. it looks a little difficult, but when I pondered over / googled further I see it is possible, may not be to truly agile, but to apply certain principles of iterative development.
Any thoughts and ideas on this will be appreciated. Saving Changes...
Sort By:
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
The real difficulty will be in your ability to fit something valuable in each sprint. You may find that you need to make the sprint longer than usual, say four weeks instead of two.
I expect your features would be a list of facts and dimensions. While it may be easier to add facts after you have some dimensions, you can modify the typical snowflake model to start with your fact table and building aggregates in intersecting tables.
Of course, if you can fit a fact table with a few dimensions in one sprint, then you are good to go. Don't underestimate the impact of bad data quality. The last thing you want is to worry about it in your ETL. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The first thing to clarify is about what does means to you a Datawarehouse project. Most of the people things that is about the datawarehouse itself but it is about more than things from data to information. Second you have to understand that you do not have mix the approach (agile) with the process (waterfall, V, Spiral, Incremental, etc) with the method/methodology (SCRUM, DSDM, etc). So, no problem to apply agile. In fact, is one of the initiatives where agile best fits. Saving Changes...
Danielle RiceProgram Management Principal| Kaiser PermanenteDenver, Co, United States
The main challenge with Business Intelligence & Analytics (ABI) progrmas and projects, is the fact that in most cases, they are comprised of multiple work-streams composed of business, process, and technology components. Some of these work-streams, may be congruent with Agile techniques being applied, and others (such as infrastructure, or external vendor partner development who apply their own methods and SDLC applicable to their tool, component, or 3rd party software) may not be at all. The key is to find when such techniques would be value added and when not.
Additionally, it would always be a bit challenging when partnering with internal and other external organizations, in a project or large program, who may not 'buy in' to the concept of Agile, and may feel this is a risk they are not willing to take upon themselves. More and more organizations are moving their development and even enhancement programs and projects to Deliverable/Fixed Fee engagements. In such cases, although you as the ultimate customer would know that applying agile methods would reduce cost, speed up delivery, and reduce risk overall, when engaging vendors in such a relationship, you are, in effect, transferring risk to them. They may not be willing to accept this method or set of practices as part of the contract for delivery.
Given the above considerations, it is a judgement call on when and when not to use the techniques, and what tools/methods to apply, in any organization's culture and specific endeavor. Saving Changes...
Agree with Stephane in that the sprints may need to be 4, or even 5 or 6 weeks depending on the "story". Agree with Sergio that DW projects are very suitable for agile, since the Data Warehouse should be built incrementally, regardless of whether an Inmon or Kimble architecture is used. Saving Changes...
