From Data to Insight – Agile Tableau

(Edit: a previous version of this post did not make it clear that Andy Cotgreave was the source of the inspiration for the “squiggle” applied to Tableau, the post has been updated to make that clear).

In this post I want to talk about the process of creating dashboards in Tableau and how people can make mistakes managing that process when they set out. I then want to lay out a method we use at The Information Lab to create dashboards for clients and why we think it is successful.

So you want to create more dashboards? Faster?

If you purchased Tableau because it helps you create the charts and dashboards you need a lot faster than you could before, replacing a traditional BI solution, then I am willing to bet your dashboarding process looks something like the below:

Creating dashboards is simple right? You know what your end-users want to see and therefore you create a set of dashboards that give them what they need. Tableau is a fantastic piece of software for quickly creating charts and dashboards and making them interactive, your users will be wowed by the speed that you have given them their new dashboard and they’ll be happy, right?

When a project is created in this way, then yes sometimes it’s perfect and everyone’s happy. Often you’ll look at the usage stats on your server a few weeks later and…oh no…they stopped using it.

The path to insight isn’t a straightline

Why do people stop using the dashboards in the process above? Normally because it wasn’t the dashboard they needed, it was some insight.

insight. noun. an accurate and deep understanding

That’s easy to say but harder to achieve, how we give our end users something they don’t even know themselves. The solution is to go on a journey together, and the result almost certainly won’t be a straight journey like it was above. As Andy Cotgreave referenced in a talk at the Tableau Partner Conference 2016, from which this post draws some inspiration, it will probably look something like “squiggle” by Damian Newman  :

Reinventing Agile for Tableau

Building on what Andy said then clearly there is a need for a more agile process to manage this journey and so, by borrowing from Tableau’s Drive methodology, as well as refined using our Data School projects a template (we use this method with our junior consultants in the school for all the projects they do in their time with us).

So yeah a fast turnaround dashboard development process suited for Tableau. You may feel that less than a week isn’t long enough to produce complex dashboards, I would encourage you to still timebox them and then start again following a period where the user has got used to their dashboard. This period of around a week is essential to allow the user to think about the data and insights, their questions may well have changed by next week.

So where did our first process go wrong? Let’s explore the main reasons we often see dashboard creation processes go wrong and see how our new process fixes it.

• Long development cycles: A lot can be accomplished in Tableau in a short time, and there is a tendency to draw out the development cycle longer than necessary, meaning energy slowly dissipates after an initial creative burst. Our aim in the new process is to keep the energy high.
• Project Management: Manage the pipeline of dashboards that need to be created but not the process. Trying to control the process too tightly can involve too many people. Instead we look to create time-boxed development cycles and leave dashboard creators to liaise with users or project owners directly.
• Lack of touch-points between creators and end users: ensure feedback happens live or in meetings, and not at artificial points in the project.
• Too much documentation: Change control slows down processes and can demoralise requestors and dashboard creators. Let projects evolve and then document pre-release.
• Aiming too broadly: Dashboards should aim to answer one key business question or have one primary function; dashboards that are too broad tend to not satisfy anyone’s requirements. Time-boxing the deployment helps prevent that happening.
• Ignoring self-service: enabling users to self-serve in Tableau can help them get insight very quickly, projects which ignore this and try to deliver everything via dashboards can end up over-reaching. If you find the user trying to take the mouse in the kick-off meeting then buy them a copy of Tableau desktop – you’ll make their day.

Ultimately we feel our process gives the user full insight into their data by involving them, live, in the process and giving them full sight of how it develops.

Let us know your feedback

How does our process compare to yours? What do you think works? What doesn’t? Let us know in the comments below.

Chris Love

Nottingham, UK