| Table of Contents: |
As organizations try to find better ways to meet the business needs of users who seek more actionable and relevant information to help them do their jobs, the adoption of agile development is popping up on more BI dev teams’ radars.
According to Ken Collier, senior consultant in business intelligence and agile product and project management for Cutter Consortium, an IT advisory firm comprised of numerous independent consultants across North America, the main principle behind agile development is an iterative, evolutionary drive toward progress. As an expert in agile BI, Collier encourages many of his consulting clients to progress in baby-steps, producing bite-sized deliverables in rapid-fire, two-week cycles. The idea is to be constantly rolling out new features on the fly, offering a more nimble response to BI users’ needs and wasting less time on features that will never be used.
“It’s not a sequence of things that you must do in order to call yourself agile,” Collier says. “It’s really much more of a set of values, principles, behaviors and attitudes supported by some very well understood practices like test automation that make it possible.”
While the agile philosophy has taken much of the development world by storm, in-house BI dev teams are still taking their time to adopt the mantle of agile for producing intelligence applications. Collier believes agile BI is about where the rest of the software community was four to five years ago in respect to agile adoption.
“My sense is that database folks, and especially the data warehousing folks, don’t believe that the agile methods fit very well for them,” Collier says, “like there is something special about what we do in business intelligence that’s unique and different and harder.”
He disagrees. He believes that BI can benefit greatly from agile adoption and he’s here to explain to Smarter Technologies six essential tips for making it happen.
Involve Users Early and Often
Customer collaboration is one of the most critical elements to making agile a successful strategy.
“If I had to only choose one thing that I would really knuckle down on, it would be getting involvement early from the user community and having them be engaged and involved every week throughout the process,” Collier explains.
As he puts it, under the traditional model of BI system development, the dev team solicits requirements up front from the user community, developers put their heads down for many months of work and then they go back to the user community with features only to hear, "Well, that’s not really what I meant when I said I needed this."
By maintaining a constant stream of communication with the user base, developers can ensure that users get the features they need, the way they need them. Collier realizes that it may be a challenge keeping up this level of collaboration.
“We see that a tension—not an unhealthy one, at that—can develop between asking for involvement and engagement from users while also respecting that they’ve got their own work to do and they’re not full time on this project,” Collier says. “That’s why I say it’s one of the single hardest things to get right.”
In spite of this tension, Collier says that BI teams should not simply depend upon business analysts to act as advising surrogates for the customer team. While analyst input is critical, if you want the entire user community to use the BI systems then you’d better get input from representatives throughout that community.
“If you’re getting weekly acceptance of new features from your business analyst group and then you roll out a system live only to find out that your BA’s aren’t really the accurate voice of the users, that can be a problem,” he says.

