Does calling something “new and improved” make it true? In the case of Agile Business Intelligence, the answer is a resounding “yes.”
I’m reminded of a time when being in the sun meant wearing suntan oil absorb the sun’s rays and to get the deepest darkest tan possible without burning. Then at some point the sun became evil, and we all started wearing sunscreen to block the sun’s rays. The funny thing is that it’s the same product with a different marketing spin. I love marketing, I used to be a marketer.
But does a new name really mean a new solution? Marketing has a way of playing fast and loose with “new and improved” labels, whether physical or figurative. But in my opinion, this one (Agile BI) has legs. When you consider that according to Gartner, 80 percent of Business Intelligence projects fail. Any improvement in this statistic would be fantastic for businesses.
Applying an “Agile methodology” to BI has the promise of several business advantages. It changes the way business intelligence projects and services are run, and it moves a few goalposts. At the same time it also relies on some time-honored principles for what to do – and what not to do – to be effective.
Two Major Steps to Really Meeting Business Needs
Agile methodology in BI offers at least two important innovations. One is in the continuing process of smaller, more frequent releases of functionality or services to users, rather than one big one after a long development or implementation period. Let’s face it, it’s impossible to sit down with a bunch of end users and stakeholders and get them to agree on much of anything let alone on everything even before we start implementing! Eating the elephant in small bites just works better.
The other is in reaching out to the end-users for buy-in of the project. This is where the real benefits of BI are achieved for any enterprise. Implementing BI in a vacuum or as an introspective IT project that excludes end users, has red flags taped all over it.
Agile BI – Here, There…
Operationally, the effects can be seen in:
- Software development. In Agile BI, development teams work closely with end-users, delivering functionality and tools that users need, as they need it, and constantly using end-user feedback to maintain or improve quality. It works, I’ve seen this first hand. Around here, we call it “collaboration” and “Rapid Development Environment”.
- Project management. Changing business environments mean changes in requests for functionality. Agile methods allow project management to work closely with end-users and stakeholders to continually steer the BI solutions course that’s best for the business.
- End-user empowerment. User-friendly self-service and cloud-based BI solutions bring end-users a new dimension of independence and avoid the bottleneck of the IT department’s “to do” list.
Agile BI doesn’t escape the debate on enterprise information architecture versus responsiveness to user requirements: the “Inmon or Kimball” choice. We have this argument around here all the time. Inmon methodology favors a unifying design before starting development of software solutions. By comparison, Kimball methodology advocates the deployment of individual solutions as a priority, giving it a more immediate alignment with the concept of Agile BI. Pick what works for you, we favor Kimball and have had much success in doing so.
Iterating towards Excellence
Lately I’ve been hearing grumblings about needing to have all the i’s dotted and t’s crossed before we can get started on a project. Management buffs will tell you, don’t aim for perfection – aim for excellence. That’s also a key idea in Agile BI.
A big advantage of the frequency of project releases, measured in weeks rather than months or even years, is in avoiding the risk of implementing a BI strategy that end up miles away from where your company needs it to be. We are just at the beginning of BI bringing value to organizations, and the business environment and BI are changing so fast that long development cycles with little end-user input can quickly end up at a huge tangent away from anything of value to end-users.
Welcome Back, Scope Creep – All is Forgiven!
And my favorite benefit of Agile BI: project scope creep can be accepted and handled as part of the process. Yeah!
Even as a seasoned professional, I get inspired half way through a project and I want to change the spec. So how cool is it that this is a logical consequence of the goal of the Agile approach? It allows us to change our minds to meet the increasingly frequent changes in business requirements. With little or no penalty! For project managers and developers that fought scope creep tooth and nail in the past, this aspect of Agile BI on its own is nothing short of a revolution.
So put on some sunscreen or suntan oil, which ever you prefer, find the perfect lounge chair, put on some music and imagine all the things you would do differently if you had the chance to be a little more agile.