Don't even think of a metrics dashboard!

Pieter Rijken

I used to be a big fan of tools. I still am.....but not as big a fan as I used to be. This changed after I realized the meaning of ‘Individuals and interactions over processes and tools’. Especially the "interactions over tools" part. This week's blog Eat your failure cake! Learn from your mistakes. motivated me to share one of my failure cakes with you.

At that time I was the project manager and scrum master of a software development team. As a team we embarked on our exciting mission to develop a new product. We did this in a Scrummish, more or less Agile way.

We set-up a continuous integration environment and we measured a lot of things. The metrics we collected included #PMD violations, unit tests ok/failed, #FitNesse tests ok/failed, code coverage, cyclomatic complexity, distance, velocity, etc.
For the product we knew that performance was going to be very important. So we ran various automated benchmarks on a daily basis. The results were collected automatically by the build system and stored in a database for reporting purposes.

Besides that I needed this to report to management, it was also quite fun to implement 🙂

Dashboard

Then I had a brilliant idea: it would help the team if I would make all this information available on a dashboard! So I spent a couple of months (including lots private spare time) implementing this based on JBoss, Pentaho Portal/Reporting, and MySQL. While implementing this I learned a lot about portals and Pentaho. On the portal side of it, the team members could define their own dashboard and view on the metrics. Cool.

Except.....nobody (except for myself) looked at it.....how come?

Coffee Machine

In the weeks that followed going live with the dashboard it struck me that team members stood by the kanban board discussing possible bottlenecks and what to do about these. The kanban board happened to be within 2 meters of the kitchen where the coffee machine stood.

So what happened was that every time people went to get a cup of coffee, they gathered by the kanban board (because the kitchen was too small) and discussed the latests events and what to do about it!

.....the next day I printed some of the most important charts and stuck them at an empty spot on the whiteboard. Guess what happened!

Conclusion

Before deciding on a tool think about what you want to achieve with it. In the example above the goal of automatically collecting metrics and create charts was OK, but having an electronic dashboard to replace interactions within the team was not a very good idea. That was time to eat my own failure cake, with a cup of coffee.

Comments (3)

  1. Friso - Reply

    September 30, 2011 at 9:54 am

    Metrics generally don't help create better software. Discipline and knowhow do.

    We could possibly invent a metric that automatically makes subtle changes to the code that don't break compilation, but do change semantics. Then the metric would be how many tests break with the modified code. If this were properly implemented, I could possibly live with it as a metric...

  2. YvesHanoulle - Reply

    September 30, 2011 at 10:32 am

    I heared of a company were a team printed of the burndown chart to hang in the toilets. They knew they had a busy CEO, going to the toilet was one thing they were sure that he did at least once every few days in the office.
    It increases communication a lot.

    Yves

  3. Agile Scout - Reply

    September 30, 2011 at 3:51 pm

    +1 to Yves.

    I was thinking along the same lines.
    Put a coffee machine near your kanbanboard + put information radiators around the coffee machine near the kanban board.

Add a Comment