Agile Working: Customer-focused BI Development

Agile Working in BI Development

At Peak Indicators we’ve forgone traditional consulting methods like waterfall in favour of the agile methodology. Agile is a process that was originally developed for software development – where the business (product owners) are constantly involved in a feedback loop with those developing the software. This means that agile is a more customer-focused process which allows the business to drip feed their feedback over the course of the whole project – which in turn means that developers can fit fixes into their schedules rather than having a glut of fixes in UAT.

How does Agile work?

Agile works using the concept of “sprints” which are short bursts of development with clear targets. Sprints are split into 4 stages:

  • Sprint Planning; this is where the development team and scrum master (the project manager equivalent) meet and discuss the plan for the upcoming sprint (e.g. what the targets are, who is available, and who is doing which tasks).
  • The Sprint; where the development team get their head down and work on the stories that they decided on in the sprint planning. The sprint itself consists of daily scrums – these are meetings where the development team meet and decide how to progress with stories, as well as whether the developers have any blockers.
  • Demo; at the end of the sprint, the developers have an opportunity to demo the product to the business. This allows the business some opportunity to feedback if what has been produced is slightly off mark or needs a change.
  • Sprint Retrospective; an opportunity for the developers to discuss whether they think they achieved their goals in the sprint, and what they can do to improve working in the next sprint.

Why Agile?

Agile is a great method for working as it allows a lot of flexibility from both the business-user and the developer’s sides. By planning and executing projects incrementally, rather than as a whole (as you would with waterfall) you have the opportunity to fine tune the end product in a more efficient way. You can afford more resources to development time, rather than having to sacrifice potential development time to repair issues that may come out of UAT.

It’s not just beneficial to the end-user but also the development team – building things incrementally mean that the dev team can more concisely organise and prioritize tasks. In turn this makes our job much easier, as we know what to focus on and it lowers the risk of features being forgotten. That means that there’s less revisiting and reworking old work – which is something we all want to avoid. It also helps clarify the expectations and requirements from the business.

Possible Downsides of Agile

Although we’ve found that it’s one of the best and sensible methodologies, that doesn’t mean that it’s completely without flaws. The only major downside that I have found is that although agile is great for clarifying requirements, business users often see this as an opportunity to change requirements. Yes, it’s a downside, but it only occurs if the team aren’t doing Agile ‘properly’ – as Agile would require a clear outline of the requirements before kicking the project off.

In summary – we’ve found that agile is a great method to deliver accurate-to-requirement projects in the most efficient way. With Peak Indicators being specialists in large scale data implementations, Agile is our preferred way of working as it means we can break down large projects into many phases.

Subscribe to our Newsletter

If you enjoyed this article why not get great insights straight to your inbox

Leave a comment