Michael Cobbin's Blog

Founder of Michael Cobbin & Associates

7 Ways to Improve Agile Business Intelligence Development

Agile Business Intelligence principles are based on its cornerstone of small, quick iterations focusing on value at each cycle and building quality solutions in a time-boxed way, seems to be the right fit to deliver information management solutions. However many people end up disappointed, having been given unrealistic expectations.

More often than not, organisations are led to believe Agile BI development will solve all their problems with minimal effort and therefore experience disillusionment when it doesn’t deliver. The reasons it typically doesn’t meet their expectations are:

  • Project Management not understanding the approach
  • The team moving too fast for its own good and in doing so loosing visibility of the Information Management strategic goals
  • Team problems adopting the approach where they think they are doing the right thing but for some reason they cannot tell why Agile is still not working for them

Following are some retrospective lessons on Agile Sprints:

1. Avoid Accumulations of Technical Debts

Technical accrual can occur due to several factors such as unforseen design issues or rushing to complete work within Sprint.

It’s important to improve ongoing estimation and resist the temptation to revise the Backlog looking for new work before finishing the current one. Sometimes this is difficult to accomplish in practice due to pressure to deliver new features but it’s important to manage Stakeholders expectations.

2. Avoid Overkill QA Process

Get the right balance between Peer Code review and Unit Testing. Don’t lose sight of what the Agile approach attempts to provide. The sooner the product is delivered the sooner problems can be fixed through an iterative development cycle.

3. Keep Communication Flowing

The success of any Agile BI project relies on fluid communication between all team members, starting from the user, through to the Product Owner, Business Analyst, Data Architects and Developers.

Foster and nurture an environment in which everyone feels comfortable asking questions and providing answers.

4. Less is More

It is well understood that doubling up resource numbers in a project, most of the time, does not guarantee double the delivery speed. In fact, the opposite is true.

Our experience has shown that teams of 5-6 developers proved to be a good number, making Daily Stand-ups, Story Conference, Task Planning and Retrospective sessions quicker, sharper and more ‘agile’. Unfortunately bigger teams, most of the time, tend to provide several vices of normal development approaches; long meetings (most ending in boring and unproductive ones), communication gaps, etc.

5. Shorten the Learning Curve

Avoid initial misunderstandings or wrong assumptions that can prove costly down the track by having an induction process with team members prior to work starting on a new subject area.

It is extremely useful to carry out a ‘soaking’ session among all team members. The objective of this is to transfer tacit knowledge from Analysts, Product Owners and Data Architects to other team members. The briefing should include:

  • What the project is about
  • What you are trying to achieve
  • What you are measuring

Analysts and Product Owners should explain the business process, while Data Architects should run through data models whenever possible.

6. Team Members Need to be Accountable

Agile teams are expected to be responsible and disciplined in order to get the right level of accountability otherwise the whole Agile experience can fall apart. Small actions such as failing to log daily work can affect Sprint visibility (why does my Burndown Chart look constantly flat if developers were at their workstation yesterday?) or failing to responsibly estimate Story Points could affect the “holy grail” of Agile; Velocity, or failing to finish a Developer Story when picking it up from the Sprint pool.

Foster an open and honest relationship among the team stressing the importance of the fact that the whole is greater than the sum of all its parts.

7. Don’t rush it, Task Plan it!

The Agile approach sometimes is perceived as the developers rushing to code straight away. Agile principles do not discourage design activities, what it does discourage is a long Design Phase found in traditional approaches such as Waterfall.

There is no right or wrong, mix design with Agile practices to your own benefit. Next time you estimate your work in your Task Planning session, make sure to factor time for your design activity so surprises are kept to a minimum.

This post is based upon a post from Altis Consulting.


One comment on “7 Ways to Improve Agile Business Intelligence Development

  1. PM Hut
    July 24, 2012

    Hi Michael,

    That’s an excellent list – I’m sure many project managers, especially those already practicing Agile, will appreciate it.

    I would like to republish this post on PM Hut under the Agile PM category, please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


This entry was posted on July 24, 2012 by in Business Analytics and tagged , , , , , .
%d bloggers like this: