Prototyping reports and graphs interactively with business users is an excellent approach to get their requirements, and show them what can be provided. To do this you need to be well prepared and very skilled with the tool you are using.
In one Sodor story, the engines all become very excited about the unveiling of a new statue. Nobody knows who the statue is of, so everyone develops their own expectations. Later on all the other engines become very jealous of Thomas, because he convinces himself that the statue is of himself, and he proudly tells this to all the other trains. They become so jealous that they start fighting amongst each other, and especially with Thomas. Meanwhile the statue was actually of all the engines together, and eventually after the unveiling did they become friends again. It’s all about perception…
In my previous post I discussed how to balance the scrums with the users against implementing and populating a proper data warehouse “underneath” the prototypes for production. But how do you approach the scrum sessions with the users? You would not be very popular if you rock up for a two-hour session with the executives, walk in there rubbing your hands, saying: “so, ladies and gentlemen, what do you all want today?”
In an agile BI project, proper preparation becomes even more important. (See my post on Dimensional Modeling for Agile BI for another example where groundwork is crucial; it can also be used as preparation for prototyping.) Before you even attempt to scrum with the executives, you must already know what their key drivers are and how these are being measured. With a straw dimensional model already in place, you will also know the dimensions from which they would want to analyse their KPIs. If you have to demonstrate the prototype off relational source data, you can use this
knowledge to pre-construct the dimensional joins beforehand.
To have maximum impact, you need to prototype the measurements of the decision points along the strategic business processes that align directly with the corporate strategy. These will typically affect revenue or profit directly, or indicate large cost items, business process optimisation or market expansion. You then sort out the strategic business processes in priority order, unless the business insists that you first complete one business function’s key areas (which normally make the underlying implementation easier).
It is best to show the information to your audience graphically, especially if they are in the upper part of the organisational structure. This implies that you need to know exactly which graphic paradigm is best to analyse the measures they are interested in. With your prototyping tool you then display these measures in the context of their dimensions. You have to be deft with the tool and know the data well, so that you can manipulate the graphs and their dimensions on the fly.
Once your audience is satisfied with what they see, it becomes the specification for the agile data warehousing teams to implement “behind the scenes”, and you can move on to the next measure and its context. An involved audience will want to use the prototype immediately. This facilitates good interaction and debate, and livens up your agile approach.
Note: make sure that your tool can smoothly switch between data sources. Some tools force you to redevelop the reports and graphs when you switch from the production data sources to the data warehouse, if there are structural changes. Such redevelopment can affect the pace and cost of your agile deployment.
