Resource Center

How to Successfully Use Agile for BI

Three-week cycles work well. Three-week cycles work well.

Depending on your teamís size, itís tough to make valuable progress in two weeks and then have time to take a step back, review what happened and plan the next cycle. Three weeks allows us to do about 2.5 weeks of work, then spend a few days on planning, high level design and retrospectives. In addition, it frees everyone up from having Fridays with tons of meetings.

Data are features too. Data are features too.

One of the key assets of a BI project is the data itself ó you donít have to deliver reports. A successful sprint can deliver a couple of core dimensions.

Plan for refactoring. Plan for refactoring.

DW tables donít exist in a vacuum, and often you canít uncover issues by looking at a table by itself. In a BI project, youíll often uncover many of your real data issues once youíve built your complete star schema. Then you can write and perform queries to slice and dice data in different ways.

Know your constituency. Know your constituency.

If you have a few users who are analytically inclined and SQL savvy, by all means take advantage of it if you have time. Your sprint can end with a demo of queries and a period of data analysis. If not, perhaps have a couple of longer or internal cycles.

Donít forget the Retrospective. Donít forget the Retrospective.

Regardless of the meeting name or approach to doing so, one of the key tenets of Agile development is refining your approach and adapting to change. That means looking at what you did, thinking about how you can improve, and continually getting better.

Be agile, not Agile. Be agile, not Agile.

Being agile does not mean you have to follow exactly what another Scrum project did, or force yourself to use Kanban boards, or hold your team to official DSDM rules. Leverage the knowledge gained from prior work, but evolve to do what is best for yours.

Since the core principles of Agile involve adapting to change, stress the virtues of working closely with the customer and the team, and continually creating working software. And keep in mind that while adhering to rigid rules or dealing in absolutes definitely has merits in promoting consistent quality in many other aspects of work and industry, Agile in a BI environment functions best when it allows BI teams to advance client goals in a more flexible environment.

To read John Harmannís full article, click here.

Agile can and does work for BI in practice and may be more important for BI than for many other projects. Since users often donít really know what they want in BI projects, giving them the opportunity to constantly tack and adjust a projectís evolutionary progress is vitally important to success. Here are six key approaches from CBIG Consulting Principal John Harmann that have served as starting points for many BI projects.


Please note you must now log in with your email address and password.