I’m a visual person and that means that I’m better receiving information in a visual form than in any other (more about learning styles here). So being visual learner I firmly believe in visualisation as the best way to fight complexity, make things simpler and easier to understand and always promote it throughout my work. In this post I’m going to look at how information radiators, dashboards, visualisation and right metrics can improve organisation, help teams to be more self-organised and help build better products.
From my experience I found that it really helps to understand any complex problem if you just draw it’s context or visualise it in any other way. I particularly like Dan Roam’s bestselling books on that subject – they are very easy and interesting to read and give you lots of practical ideas on how to visualise various situations.
Being an aviation geek I can’t miss the chance to refer to aviation industry as an example:
Over time complexity of airplanes grew significantly from Wright brothers first flying machine to multi-engine piston aircraft to jet mammoths like new Airbus A380 or modern fighter jets that can’t even be controlled by pilot without the aid of computer as otherwise they will crash almost immediately. So as complexity of flying machine increased with growing number of various supporting parts and sub-systems amount of incoming information and factors pilot needed to deal with increased as well. And as we know, we humans are rubbish at multi-tasking and our brain capability is limited to focus just on a few things at the same time. Most studies show that we can effectively concentrate and deal with 7 ± 2 factors at any given time due to specifics of our short term memory. So to keep piloting safe great efforts were made to build better flight instruments that will gather all important information from all subsystems, organize it and display in effective and convenient way to the pilot.
Left to right: WWI plane, Concorde, A380
Even with all modern technologies you can display just finite amount of information – remember about our short-term memory limitations. So that’s why in any aircraft you can see only 6-7 main flight instruments are placed in pilot’s primary focus.
Same primary instruments on the old dashboard (left) and new HUD (right)
It’s also very important how information is displayed. To make most out of it you need to process raw data and represent it in meaningful way. On the image above modern HUD shows the same information as one on the left but it visualises it much better (notice little circle in the top left that shows direction to the next waypoint).
Alright, we done with short detour to aviation industry and I hope that I managed to illustrate my point that visualisation helps to tame complexity beast. There also many other examples like recent rise of infographics and just look at this visualisation of US budget – that is lots of data on one easy to understand image.
Let’s go back to software development. With increasing adoption of agile and lean practices and techniques we start to see more visualisation coming to help plan and guide projects. All those Kanban boards with workflow visualisation, value stream mapping diagrams and project metric reports help a lot. But what I see quite often in teams I worked with is that not many go beyond basic Kanban board with 3 lanes like “To Do”, “In Progress” and “Done” and burn chart. It’s often (but not always) better than nothing yet I’m sure that we can do much better with more effective and sophisticated dashboards.
In one of my previous posts I wrote about self-organising teams and that to build amazing products you need amazing teams (I tend to believe that product is reflection of the team that built it) and only self-organised team that is not micro-managed but rather guided and empowered and understand what it’s doing and why is truly amazing. I think that wisely mastered dashboard/information radiator can help with that. Sadly though that is often overlooked.
“What gets measured gets improved” – that quote is not always true but at least what gets measured is definitely gets attention. So you need to chose carefully when designing your information radiator what it will display. Showing right information will focus everyone in the team on the right things but showing wrong things will enforce wrong behaviour (e.g. testers rewarded for number of defects they opened). I never saw company-wide or programme-wide metrics to be displayed on the project dashboard and that is huge mistake in my opinion.
One of the core Lean principles is to optimize the whole and to do that we need to measure the whole. To empowered the team we need to give it more information and better context for things they are doing so sharing company/programme-wide metrics with the project team and displaying how project and every individual affects and contributes to them can make very positive impact.
How often you saw those pointless company share price displays in corporate lobby halls or on corporate intranet portals. I bet quite often. Now think for a moment if that is what displayed everywhere as one of the main metrics of how well company performs what do you think will be focus of executives, managers and other decision makers in that company? Most probably they will be focused on the money and stock prices first and delighted customers and good products last (hopefully not but odds are that they will).
But hey! Isn’t everyone talking at the moment that we should be focusing on customers, experiences and better products first and money will came as a result? Check out the Stoos Network, those are the people focused to find better ways than just focusing on the stock price.
Once you start focusing on the money it’s race to the bottom, thinking how to make product cheaper and cheaper you’ll probably find yourself with very low margin and shrinked profits. And what is important that growing middle class (look at China) doesn’t want to buy just cheap products, they want better products! People have money and they want to spend those money on something what works well, looks good and of high quality and not something made of cheap materials with poor ergonomics and will break shortly after purchase but costs less.
I really liked dashboard I saw at the British Airways main lobby hall – on a big screen it there was percentage of flights that departed and arrived on time and overal customer satisfaction index and how it changed comparing to the previous period.
In my opinion that is much much better than a stock price and every morning when you go to the office you see those numbers and don’t know how others but I quite often found myself thinking how can I make a difference and improve it.
On one project I worked at we were overhauling one of the key self-service pages of internet portal. In addition to standard Scrum/Project metrics we had metric that was showing size of the page in kilobytes and average time it takes to load and process in the customer’s web browser. Monitoring and improving upon those metrics in addition to others really helped us to improve customer’s experience and that’s what the whole project was about. Showing those metrics to every team member helped keep team focused and share that overall vision of why we are doing the project in the first place and how team’s work affects customers.
Alright, said enough about importance of the right metrics and effective dashboards, now it’s time to talk how to build one.
Guys at Atlassian did Wallboards Contest some time ago to collect various ideas and examples how different teams approach task of displaying important information effectively. It was great contest with lost of interesting examples (87 entries recorded) and I encourage you to check results here.
For many years most of Kanban boards were physical and made with tape, index cards and stickers and put on the walls, whiteboards and windows all over the offices. It was good for the beginning but physical board has many limitations and doesn’t really work well with distributed teams. The contest winner, Vodafone Web Team solved that problem to some extent with RFID tags, projector, label printer and webcams. Here’s their video:
They use RFID readers attached to the board and RFID markers on the cards to track and update Jira as they move physical cards on the board. Projector is displaying burndown chart over the board and every time new task is added to the jira related card is automatically printed on the label printer attached to the board. How cool is that!
I had an opportunity to talk to the Greenhopper team members at Atlassian about other ways to integrate physical boards with software solutions and they told me that some enthusiasts are trying to utilise Microsoft Kinnect controller to interact with the virtual board, solution is not production-ready yet but I expect it to be really good way to solve that problem eventually.
So when building dashboard think what to display and how it will affect team and project direction. Try to convey project, programme, company vision through those metrics and data that is displayed.
Since dashboard has limited surface don’t display what is not critical but when something bad does happen show it and make sure that everyone pays attention to that.
I also like that idea with dashboard backlighting to attract attention when it’s especially needed.
If you need to show more metrics than one screen can’t accomodate – make virtual screens and rotate them.
One metric that I like and use sometimes in retrospectives is drama-level or team happiness index – number from 1 to 10 or from 1 to 5 that shows how good is the team rated by it’s team members. Why don’t collect that metric on a regular basis and display on a dashboard?
I really like idea of Value, Flow and Quality as sort of three essential dimensions of every project or activity (read more about that here) and I’m going to review metrics from that perspective:
From Quality perspective I would monitor number of P0 and P1 defects found in UAT and production and average time to fix those defects. Application performance metrics after each deployment (e.g. if page load time or operation time increased after new deployment then we need to look at it). Frequency of the broken build is helpful and percentage of the code coverage so loved by many is good but don’t be fooled as it not always represents real picture as tests could exercise the code but not assert results properly showing high percentage but not so great assurance.
To gauge Flow I would monitor bottlenecks and WIP limits in the workflow. Size of code commits and frequency of those commits. Also good to keep an eye on cycle times of operations such as deployment and test execution.
Value probably is hardest one and the least monitored but in fact it is the most important one. The reason why it’s least monitored is due to it’s complexity and not always straightforward how and what metrics to collect. But I’m sure it’s solvable if some extra effort applied to think about it. I’d monitor things like conversion rates, sales/revenue/profits, downloads count, customer satisfaction and engagement, usability. And I’d definitely share that with the project team!
If you dashboard is accessible via web make it interactive and possible to drilldown to the details of each metric to better understand it.
And lastly apart from making it useful don’t forget to make it nice looking and fun so that it will have more chances to stay around and keep providing value. Countdown timer till the next pub crawl or something similar sounds good to me to be put on the dashboard.
If you have an example of the dashboard or metric(s) that you are proud of and want to share or any ideas good ideas in that area please add it as a comment.
Shameless Plug 
If you are in Australia and even better if you are in Sydney and want to improve your software development and delivery processes and build better products – let me know and I’d be happy to help you out!
