Founder of Michael Cobbin & Associates
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:
Following are some retrospective lessons on Agile Sprints:
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.
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.
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.
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.
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:
Analysts and Product Owners should explain the business process, while Data Architects should run through data models whenever possible.
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.
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.