So this blog post will mainly cover what dashboards can bring to transparency, which is at the core of what most IT projects are about these days, unlocking some feature set in the business or exposing a data set previously hidden away. What dashboards do is bring this transparency about what your customers are doing online in real time. I will also cover the transparency in work environments and how it relates to agile. It is also worth noting that transparency is one of the “three pillars of empirical process control” mentioned by Scrum.
The lightbulb moment for me was a couple of years ago, when I built a dashboard in a couple of weeks with Statsd, Graphite and Grafana for a client before go live. All I was doing was sending some metrics to graphite, like how long third party service calls were taking, how long different parts of the end user journey were taking and trying to relate that to business terms, so how much money was coming in, comparing journeys to different parts of the day and previous days.
As soon as metrics started to appear other developers and architects started asking how do we add different metrics. The power was already kicking in, people saw what was happening in the system and they wanted to know more. The client CIO even started asking questions when certain metrics went red and how do we fix that. This was another lightbulb moment in how to get funding for poorly implemented parts of a system that were affecting the bottom line. The dashboard even caught an issue with a third party system before the third party integrator noticed, because we were transparent about every part of the user journey. This was effectively doing real time data analytics before it was cool. We have now used this same pattern in some other client projects and bid work. Clients love this, as it adds so much value and custom dashboards can be adjusted or built for different business owners depending on what they care about.
This is invaluable to the customer and this same pattern can be invaluable in different aspects of a project like giving the customer access to reports on project costs, story points or issues closed in a sprint. Which brings me to the next example of transparency in the work environment. Invariably if you are doing development these days, you will be having daily standups, weekly reviews and client demos. All of these activities are strong examples of openness or transparency in the work environment that come about due to agile processes, but being open in the workplace also brings a lot better culture. You openly communicate with colleagues and find out each others strengths and weaknesses, which can lead to better development or just a better work environment.
Another prime example that is becoming prolific these days is open source, which one of the core principles is transparency. Groups of people getting together or just one person, to show others how cool something is or how something works in a given technology or hardware. Last year we open-sourced a piece of software, this was another piece of transparency in which we tried to document everything that we were trying to achieve and all our decisions made to date. We also have tried our best to make full guides to getting started in an effort to provide the full information required for collaboration, cooperation and collective decision making, which is the very definition of transparency. Here is the full blog post about Apollo.
Another example came up recently, where the client wanted a better view of how the project was tracking, what costs they were using for their hosting, how many deployments were happening and what artifact versions were being used. We were tracking this information on different parts of their wiki and we had set up different operational dashboards in our cloud provider, but the client wanted one place they could check on frequently. I was surprised this service wasn’t offered by many cloud providers, a more holistic view of what is happening for the service. So I knocked up a dashboard in Dashing, and plugged a few metrics in, as a starting point e.g. service availability, incidents, jira tickets open, hosting costs per environment, number of build and deployments and version deployed to each environment for each application. There will definitely be more metrics, but I figure you need a base point to start the conversation around what the client really wants us to be transparent about.
If we show we are transparent, people tend to be more open and honest and the trust relationship can really be built from a strong base. We often get greater collaboration and cooperation from ongoing transparency in projects and in our personal lives. All the examples above and patterns can be applied to our personal lives with great success.
