Agile BI, Part 2: Overcoming the business’s fears

In my last blog, Agile — Doing it Right, I covered some of the major complaints from both the business and technical teams when it comes to Agile Business Intelligence. You might recall that all of the complaints boil down to two underlying causes:

  1. Ineffective communication between IT developers and business users
  2. Lengthy development cycles

In this blog, I will zoom in on a few organizational challenges and suggest steps for overcoming them.

Too often when Agile is first introduced to an organization senior managers take it with a grain of salt. They aren’t fully on board with the Agile principle of evolving estimates and timelines. This lack of clarity makes it difficult to plan high-level budgets and schedules for the next fiscal period. For BI data integration projects the problem is amplified by the fact that, unlike front-end applications with user interfaces, BI deliverables are not always tangible. As a result, timelines for User Acceptance Testing and bug fixing can often run over. In order to make executives more comfortable, I suggest getting IT and business teams on the same page on the following important points.

  • Recognize that the precision of 30,000 foot estimates is always tentative, independent of the methodology used. You have to get further into any project to start estimating with any accuracy. In fact, Agile offers more value in top-down breakdowns than other methodologies as well as epic-level stories, each of which will describe the 30,000 foot whats, whos, and whys. Also, compared to waterfall, which at 30,000 foot level still focuses on the activities (which are uncertain by nature), agile concentrates on ensuring razor-sharp focus on customer value. An example of an epic-level user story is, “As a VP of Sales, I need my sales and merchandising functions integrated so that my staff can readily analyze the impacts of merchandising decisions on daily, weekly or monthly sales.” Note that in this example, the focus is not on specific sales or merchandising functions, but rather on the combination of features that delivers value. Therefore, as the project evolves, some features can be added, dropped or prioritized to hit budget and schedule goals, but never without confirmation that value is still present.
  • Agile’s short, fixed iterations virtually guarantee firm release dates. (With variable scope, however.) These allow the team to set reliable expectations for business UAT well ahead of time, though only in small pieces. The nature of Agile to deliver small pieces frequently actually aids business users’ understanding of each release in a data integration project because it is easier to grasp each iteration and identify the changes needed to ensure proper results. For data integration scenario, that would mean focusing in a set of changes for a specific domain within an iteration (e.g. column/table changes in customer, sales, merchandizing), rather than implementing cross-domain functionality. The approach will allow to narrow down UAT resources and clearly set their expectations, so that validation/bugfixing is completed in a reasonable time frame. Similar approach would apply for reporting scenario, with the focus set on homogenuous set of reports.
  • Finally, executives need to be educated that evolving estimates inherent to Agile, while somewhat frustrating, are based on a solid process and scientific foundation. Agile Estimating and Planning by Mike Cohn can serve as a great reference to help with this. Explaining Agile-specific concepts, like estimating techniques (planning poker, expert opinion/analogy/disaggregation approaches, reestimating rules), scheduling (e.g. releases based on value, not features), tracking and communicating metrics (e.g. velocity, burndown, planned vs. actual progress updates) will help to establish trust, to provide confidence and establish realistic expectations with the business. The book describes in detail a scientific approach to estimating, planning, monitoring progress, and communicating results at various stages of the project.

In my next couple of blogs I will cover more organizational and technical challenges of introducing Agile BI in organizations, as well as share my experience to help overcome them. Stay posted!