Making Your Business Intelligence Team Agile

So, you think you can’t make Agile work within your business intelligence team?  Think again.

Agile business intelligence isn’t new; many people have written about it.  It’s mature enough now to have a smattering of books lining the shelves. What are these books based on? Experience. People are executing it and have been for some time.

At Daugherty Business Solutions, we have a group of those experienced professionals on our team. In fact, we have worked with a large telecommunications client for fourteen years using parallel Agile sprints to support enterprise financial performance reporting. The group in place has evolved from large teams to manageable teams of eight, and members have cross trained between ETL and data visualization tools.

The evolution of these teams was not an accident, but instead an orchestration of the Agile methodology. Some people may think of the term Agile and wonder if that applies to business intelligence in the same way that it does application development, and there is no doubt that there is a difference between the two. But, the specific factors differentiating these doesn’t need to be standing in the way of organizations realizing the benefits of using Agile principles to bring more value to their customers, more quickly, and with less overhead.

So, how do you do it?  Before making that determination, there are two key things that need to be identified.

First, data projects are different. You have to acknowledge it.  Sing it from the rooftops! Just like we cannot use exactly the same team and methods to successfully execute a Waterfall application development project and a Waterfall data project, we certainly can’t use the same team and methods to execute an Agile application development project and an Agile data project.

For example, Team Daugherty is working with a cable company’s business intelligence group to build Agile capabilities into their current teams. As we launch projects with them, we’re working through our planning sprints and introducing an additional sprint to allow for some of the coordination and planning required when implementing projects. This is important when using full enterprise data stacks and fully mature data warehouses. By planning more up front, we’re able to fully implement Agile practices, and we are seeing an extremely positive response from our business partners.

Second, because information management projects are different and have different players, characteristics and challenges, we’re going to have to let go of some of our purist notions of Agile.  Think for a minute about this question: what is Agile at its core?  Is it ceremonies?  Is it a product backlog? Is it cadence? Agile is not one of these things. These are all things we do within specific Agile methodologies. To be Agile is to generate value for the business in a consistent, timely manner. The rest are just rules.

Does this mean that we want to throw all of these guidelines out the window? No! What it does mean is if a particular rule is preventing us from achieving our goal of realizing the benefits of Agile, we should evaluate it for validity within the information management discipline and weigh that against how that particular rule helps teams realize specific Agile benefits.

This is true for a number of the projects we are working on right now. One that is top of mind is a project that has Daugherty working with the business intelligence group at a retail client to define how Agile principles will be applied on their teams. As we know, one size does not fit all. In this IM project example, unlike application development projects, it does have some stories that must be executed in a specific order. Working together with the client’s teams and product owners, we’re redefining how the stakeholders prioritize features and the value produced in each sprint, knowing that some of our work items must be executed in a specific order. It may be a specific Agile rule that work items are designed to be interchangeable and can be re-ordered at any time, but we know that, in this situation, that is not what is going to lead us to be the most successful.

Just remember, we’re going to have to let go of “purist” rules and methods, weighing them carefully against the value they bring. Through our work we know that it has to be okay to sequence some work items in a specific order to deliver value to the business.

When working as a part of an Agile team at Daugherty Business Solutions, I have learned that we value “value” more than rules.