If you are in a BI management role I am sure you will turn your head if you hear this two-word combination: Agile BI. For the last six years I have been working for Coherent Solutions, Inc. as a delivery/project manager and BI practice lead. My primary professional interests lie in project management methodologies and business intelligence, so naturally agile BI has been at the center of my attention for all these years.
In most cases, the benefits of switching from Waterfall to Agile methodology are clear: greater transparency and engagement of business stakeholders; the ability to work with evolving requirements; adjusting priorities on the fly; and shorter delivery cycles – just to name a few. But although I’ve participated in a number of successful organizational transformations to an agile environment, I have yet to see a BI department fully implement this approach with success.
In this series of blogs I will walk through the process of transforming a BI Waterfall environment into Agile Scrum, starting with identifying issues that Agile aims to handle better. (Covered in this blog.) Later I will identify the organizational and technical challenges that come with implementing Scrum, and my suggestions for resolving each of them.
In my experience working with a number of BI departments, whether in large or small organizations, powerful or not, there are definite trends in the complaints from both the IT and business sides. I attribute most of these to some variation of the Waterfall methodology used.
Business side complaints
The most common complaint from business users is that their IT team does not fully understand the business’s BI needs, which results in delivery of functionality and data that do not match the requirements the business thinks they asked for. To get to the bottom of this problem, the real questions that need to be asked are:
- Do the business users take enough time to think through and write good, detailed business requirements?
- Does the business side spend time with the technical team beyond the requirements phase to fully understand the design and impact of the technical solution? Or once they believe their requirements are understood, do they provide a blanket sign-off without examining the plan?
- How thorough is the user acceptance testing process? Does the business work with the IT quality team to ensure that test cases address business concerns?
Other common business complaints include:
- IT lacks flexibility in accommodating even small changes in requirements, resulting in long delays for seemingly small functionality changes.
- A constantly full pipeline of projects that makes wait times seem outrageously long.
Tech side complaints
Now let’s take a quick look at similar issues from an IT standpoint. Complaints from the technical include:
- Inconsistent requirements from the business
- Constant requests for changes
- Unreasonable timelines
- Different projects with overlapping requirements and dependencies, making it impossible to release one project without the other – which results in extended timelines.
It is evident that all these issues boil down to two underlying themes:
- Ineffective communication between business users and IT developers, and even between different business departments
- Lengthy or extended development cycles
Agile specifically addresses each of these issues, and in order to set the stage for successful migration to Agile, it is critical that both IT and business management recognize them.