For years, I have ranted against traffic lights as a way to discuss project status. That’s because on serial lifecycle projects, or on long projects, the traffic light was always yellow or red. And, because managers, especially senior managers expected the light to turn green by itself with no outside intervention.
But Lisa Crispin noted at Belgium Testing Days that her project was mostly green. It’s an agile project, and the build mostly works, and the tests mostly pass. It’s a rare day when things don’t work.
And, now my friend and colleague Yves Hanoulle has another really good use of red and green highlighting in a report that shows more testing, fewer warnings, unreachable code detected. I really like that unreachable code detected!
The nice thing about using red and green is that red means stop and green means go. It still doesn’t help the color-blind people, but it’s a nice use of the contrasting colors for those of us who can see the colors and understand that if we want to fix something we’d better.
For me, these uses of red and green are different than the traffic light project status. For one thing, they are binary status: either red or green, not yellow. And, the teams’ reactions are different. Lisa’s and Yves’ teams (I suspect, I don’t know for sure) are much more likely to pounce on a red piece of data than when a project team had a yellow traffic light status.
So, I have to be clearer on how I rant about using traffic lights to describe project status. For agile projects, traffic lights, as long as they are binary and prompt people to action, are a good indication of status. For other projects, I still like weather reports.
