How to Build a Dashboard Using Agile Methodology [Part 1]
As a avid Scrum Master and amongst other things BI, a dashboard designer, I have noticed something puzzling regarding Agile and Dashboards.
When thinking about building an agile approach to dashboard projects one finds a sudden lack of ressources on the net. I feel that more information needs to be made available to better structure and define techniques to ensure a succesful dashboard project in Agile.
It is my hope to start chopping at this new block of ideas, expanding and defining the various ways we can approach how to build a dashboard using Agile. This is bound to be the first in a series of postings regarding the subject. In this post I set the main topics of discussion around what would be, an Agile Dashboard Implementation Approach by deconstructing the structural elements of a dashboard. This is the foundation of the understanding to orchestrate both database structures with front-end interface components.
Two types of developper stories
At a more technical level, we can describe and breakdown the user stories into technical, development-oriented stories. We can either describe those from a data or a feature point of view.
Remember that a dashboard supports the user’s analysis via a visual representation of data. Those two elements must be defined separately, but tied together in the delivery.
It is useful to also note that a visual element can be of two type. Either we use a visual to display data, or we use a visual to interact with data or the interface. Only purely UI interaction do not have a dependency on data. For instance, a button that opens up a windows with help information, or a image of the company on the splashscreen. Strangely, those oftentimes have good project branding impact and are low cost to implement. Think of them as a the wine accompanying your meal. They enhance the experience, but you can’t only have wine for diner otherwise … well, let’s just say the end result might not be a coherent dashboard.
Orchestrating the delivery
At the end of the day, the trick is to synchronise and coordinate the delivery into a cohesive interface that grows incrementally. The following graphic explains the dynamic of the delivery.
We develop front-end elements that are connected and fed via back-end elements, which populate the visuals. Those in turn are integrated to support KPIs and analysis needs. A incremental approach offers value throughout the delivery.
Along this “front-end” reality, we must consider that we are often building the dashboard at the same time we are building the datawarehouse. The challenge is to deliver value on the front-end while the data wrangling is taking place. We must therefore merge the work stream of the front-end team, the dashboard team, to the back-end team, the ETL and datamodelers. This of this a having to build a fonctional kitchen while the house is still being built.
More to come in later postings…
Now that we covered the building block of the agile dashboard, next time I will propose two agile approaches that we can use to deliver value to the interface.
In resume
Like any other agile project, coordination of the delivery for incremental customer value is critical. Databases have dimensions and fact tables, but dashboards must also be considered by their subcomponents. For a dashboard project that combines building a data foundation at the same time, a successful incremental delivery will orchestrate both notions as one, folded into a hollistic user experience.