The 12 (or so) Myths about Agile Business Intelligence – Myth 2 There is No Need to Produce Documentation When Using Agile BI Methods
by Jim Gallo
Originally published October 26, 2010
This article is the second in a series that will address the 12 myths about Agile business intelligence (BI). You can find the complete list on my BeyeNETWORK blog. You can read the full article on Myth 1: Agile BI is Radical and New on my ByeNETWORK Agile BI Channel.
To make matters worse, we then walk them through data models, asking them to validate that the model is correct. We hand them something like this…
(mouseover image to enlarge)
…and expect them to “see the business” through the model. The problem with the Word documents and the data models is that we are expecting the business to see itself as we in the IT profession do, when in reality the business may have only a faint idea of what they are being asked to review and approve. The reality is that the business sees itself like this:
…and not as a series of words on a page or as an entity-relationship diagram. And what’s even more important to recognize is that the historically verbose and technically bent documents have a life span that’s shorter than a mayfly.
Be of good cheer! A new class of tools is rapidly emerging that allows BI teams to capture, model and maintain business information in ways that are accessible, reusable and, most importantly, understandable. The best one I’ve seen is Balanced Insight’s Consensus that’s been woven into my company’s Agile BI delivery model. I am absolutely convinced that using tools such as Consensus drives down overall delivery costs and enhances a Scrum teams’ ability to maximize the amount of work not done through elimination of redundancy and rework and through the production of outstanding artifacts and documentation.
While I’m on the topic of “maximizing the amount of work not done,” there is something that Agile BI teams (heck, all BI delivery teams), need to take to heart. There is no value in sourcing data for data’s sake – something that seems to be more pervasive than waterfall projects. If you believe, as I do, that 60% to 70% of business intelligence/data warehousing (BI/DW) delivery and the vast majority of project risk is associated with data integration and data quality, why, for Pete’s sake, would anyone in their right mind source more data than is needed to answer the business questions (as defined on the story cards)?!!!! Take another look at the Agile BI process I introduced in debunking Myth 1.
(mouse over image to enlarge)
Note the transition from the Business Value Chain to the Technical Value Chain. Candidate sources are identified from the business terms. Source analysis and data profiling tasks stem from the business stories and can be traced back to them. In other words, if there is no requirement to source specific data sets, then DON’T DO IT as it only adds to project costs and risks. Even if you do not see a need to adopt Agile BI methods, I really encourage you to adopt this particular practice.
To sum it up, Agile BI methods do indeed produce documentation needed for design, test, support and compliance. Documentation gets planned along with each Sprint and the documentation tasks are expressed as individual story cards. While we still can’t avoid creating some documentation in Word, Excel, PowerPoint and Visio, tools are available today that can alleviate some pain associated with producing and maintaining documentation. Just as importantly, these tools can be woven into the Agile BI delivery process to help improve velocity and decrease defects.
Look for my next article on Myth 3 – Agile BI methods do not support sound BI/DW architecture principles. Cheers!
Recent articles by Jim Gallo
Copyright 2004 — 2020. Powell Media, LLC. All rights reserved.
BeyeNETWORK™ is a trademark of Powell Media, LLC