Agile Business Intelligence: Increasing the Velocity of Reporting and Analytics
By: David Crolene and Donnie Evans
One of the biggest complaints we hear from business users is that it takes too long to develop reporting and analytics when working with IT. Some BI programs have turnaround times ranging from weeks and even months from the time a business unit requests a report. By that time, the business has often found a different source for the information, or the issue or no longer relevant.
This is where Agile Business Intelligence comes into play. By joining forces with the business user community, we increase the capacity to deliver data faster and with quality, while still ensuring that IT best practices are upheld. This offers the promise of stability and supportability, while providing more rapid turn-around times. Ultimately, the business is empowered to make decisions based on high quality data, but also in a timely fashion. However, the promise of Agile Business Intelligence is not always easily obtainable.
A recent project with a major Real Estate company gave us a chance to walk through some of the innate challenges with Agile Business Intelligence, some of the benefits and our observations on key success criteria for an effective Agile Business Intelligence project. This paper will focus on Agile Business Intelligence, as it relates to reporting and analytics.
We recently completed a multi-month end-to-end Data Integration and Business Intelligence project with a major Real Estate company. This project included two major releases.
The first release utilized MicroStrategy for performance reporting and analytics atop an agent membership data warehouse (DW). Reporting and analytics centered on key performance data for agents and offices, as well as demographic data. Reports were delivered on a variety of agent count statistics with the highest profile report being a daily agent count report that is sent to key executives.
The second release focused on financial reporting and analytics atop a financial DW sourced from JDEdwards E1. These reports were formatted to support distribution to the client’s executive leadership team. Some reports provided the ability to drill down into detailed account balances.
A final Revenue Dashboard was then created to combine financial and membership data. This provided upper management with a view that correlates business changes with financial impact.
Agile Business Intelligence was utilized across all phases of the project. This customer was relatively new to the Agile Business Intelligence project management approach and had limited experience with MicroStrategy. This helped to expose some of the inherent challenges with Agile Business Intelligence during the project.
Agile Business Intelligence Challenges
During the course of this project, the team was able to experience and capture some of the on-the-ground challenges with Agile Business Intelligence.
Reporting versus Meta Layer (Architect) Changes
With MicroStrategy, as with many BI tools, one must consider report development vs. Meta Layer/Architect changes to the semantic layer. While working with an end-user, one must not only consider iterating a specific report, but also potential changes to the Meta Layer/Architect. One wouldn't want to fix a display issue in a specific report only to turn around and have to fix it in every single subsequent report. There are times when changes are either preferred or required in the Meta Layer / Architect. Such upstream changes may take a little longer to accomplish, but follow best practice and often this time may be made up in later iterations.
Reliance on the Underlying Data
Business intelligence reporting relies heavily on the underlying data warehouse design. While working interactively with business users, it sometimes becomes apparent that certain data elements are missing or incorrectly displayed. In this situation, there is often little that can be done directly within the BI tool to resolve the missing or incorrectly defined data element. No matter how flexible we try to be when it comes to agile report development, if the data elements aren't part of the warehouse, there will be a longer waiting period to have the desired elements added to the data warehouse. That’s not to say it can’t be done, it just means that the turnaround will take a little longer and expectations must be set, accordingly.
Variable Nature of an Iteration
From the image below, one can see that when the scope of an iteration resides strictly within the reporting layer, it is most simple. If the scope must expand to include the Meta Layer / Architect to accommodate system-level changes, one must consider a broader range of variables. And when the scope expands further to the Data Warehouse layer to add missing or erroneous data elements, the scope of the iteration can become substantial. This variability that is often only exposed during report development can be a challenge for a Scrum Master when estimating and planning iterations.
Keep an Eye on the Strategic
We found that when business users are exposed to a low-level tactical level of detail, sometimes they tend to focus too much on the tactical aspects of the project and lose sight of the strategic goals. It is, therefore, crucial for the Scrum Master to stick closely to the Scrum user stories and bring the focus back to the overall strategic goals of the project. This leads us to the next challenge… scope control.
It’s one thing to be flexible in helping the business achieve its goals. That is one of the key benefits of Agile business intelligence. However, it’s another thing to make changes to the point where progress stagnates. A primary goal is delivering quality information in a timely fashion. This creates a balance between being flexible working with the customer and finding the level at which the solution is “good enough”. Sprints may help contain this challenge, however, sometimes certain features can fall victim to others. This doesn't mean that requests be ignored. It does mean that those requests have to be documented and prioritized for future inclusion. This is where a strong Scrum Master can ensure that the scope is based on a user story and once the story is satisfied, the feature is deployed.
Team Commitment & Training
One of the key tenants of Agile business intelligence is that the business user work side-by-side with IT on a daily basis. This has to be a priority for the business in order for Agile business intelligence to be successful. By ensuring project sponsors understand this and convey the importance to the target business users, a project leader is much better positioned for success. This top-down approach will emphasize the commitment that the project sponsor(s) have for the project and help motivate the people on the project team.
Along with the IT and business relationship, it is very important that everyone on the IT project team is committed to the Agile business intelligence process. Non-adoption of Agile business intelligence on the project will make success much more challenging.
Part of team commitment also includes sufficient training. The entire team, sponsors, business users, and the IT team should all be familiar with Agile business intelligence principles and methodology before the project begins.
Comfort with Change
Some business users are uncomfortable with frequent iterations being pushed to production without the typical project gates found on a waterfall-style project (e.g., SDLC). When business users are comfortable with a more fluid environment and frequent change, the project team can iterate features (e.g., new BI reports) into production without having to continually defending the deployment.
Agile Business Intelligence Benefits
Agile can be very successful when applied to BI reporting and analytics. Numbers like 20-30% project performance improvement are commonly cited. It is no wonder that using Agile for BI reporting and analytics has been so popular over the past several years. Below, you will find some of the practical benefits of Agile business intelligence that we observed during our recent project.
It is our experience that when harnessing a typical Waterfall style project, no matter how long and thorough the requirements phase, when it comes to reports, business users aren't sure what they do and don’t want to see until they have something on the screen in front of them. By sitting with business users when the time comes to start developing reports, an Agile business intelligence approach is well suited to support the iterative nature of a typical report development initiative.
By working through the report development with an end-user sitting alongside IT, the process of fine tuning formatting happens much faster. This may be achieved with a waterfall approach; however by combining the report design portion with development, we condense the cycle time. Plus, involvement in design, development, and testing gives the business users much more insight into the process and enhances their sense of ownership.
Calculations are frequently a key building block of a report. Understanding the data and what it should look like is the job of the SME. By embedding subject matter experts (SME) in the team, we find we can quickly and accurately answer questions regarding calculations that may be needed within reports. This translates into faster testing processes, as well as, user acceptance. Since users were involved from the beginning, they are more confident in the delivery.
By embedding business users within the project team, they have a much better understanding of how the development process works and typically take more ownership of the solution. Their voice in frequent recurring meetings also provides a direct conduit from project sponsors into any level of detail regarding the project status. This helps the sponsors to get a realistic perspective as to where the project stands so they can immediately address risks, challenges, and issues.
By having business users involved in the development process, we provide the opportunity to train business users with business intelligence tools during the course of the project. As their proficiency in the tool grows, their creativity will also continue to grow and they can then harness the full capabilities of the tool. This has a secondary effect of pushing the capabilities of the BI tool with the vendor to keep growing their product lines to meet the ever expanding desire for information.
Some of the factors that we have observed that lead to the success of implementing Agile business intelligence with reporting and analytics include:
A Trained Team
One of the biggest factors of a successful Agile reporting engagement is having the proper people working together on a cohesive project team. This team will be collaborating daily, so the correct mix of skills and personalities needs to be addressed early in the process. Both sides of the team (business and IT) will need to get comfortable with a fast-paced, rapidly-changing environment. This team must be trained on the principles of Agile business intelligence and the use of management tools being used by the Scrum Master.
From the business side, it is imperative to have someone with the business knowledge and authority to help navigate the daily challenges that arise on any BI project. Ideally, this business user should be willing and able to undertake the role as reporting power user and take on training duties after the completion of the project to ensure post-deployment continuity.
A talented scrum master is essential to the success of an Agile business intelligence project. The Scrum Master will manage the scope of the project and make sure that sufficient time is allotted to prioritize tasks and contain scope creep.
In order to meet the evolving and increasingly demanding reporting needs of today’s businesses, a more flexible approach to developing business intelligence reports is essential. Thoughtful implementation of Agile Business Intelligence can significantly enhance the velocity of a BI project team.
If an organization is not completely ready to embrace the Agile business intelligence methodology, adopting agile principles for BI development can be very beneficial. These principles tend to embrace concepts such as heavy business involvement and small manageable iterations that are frequently pushed into production.
Are you ready to discuss your project?
Let's chat about it, we look forward to helping and becoming your data partner.