I am continually surprised by how many traditional activities and behaviours survive long into an agile transformation. The Red/Amber/Green status reporting is one of them. Even allegedly Agile people seem to hang on to the RAG status like a comfort blanket, but in my experience, it has little, if any, benefit. And the reason is that each status colour causes certain behaviours, which are, at best, served in other ways, and at worst are counter-productive. After all, what are they actually measuring? A subjective opinion on the part of the person doing the reporting of the status of the project. Or rather, what he/she wants the stakeholders to hear.
What happens when the status report is Green? In my experience, few busy executives read any further. If the status is Green, why should they worry about it? Mentally, they may pat the project manager on the back and think ‘Good man, that. He’s on top of things.’ but that’s about all. And what’s wrong with that? It creates in some, an incentive to be… economical with the truth, especially in an organisation which lays responsibility for delivery with the project manager and not the Business Sponsor. I know of more than one person who has reported a project as Green in order to be left alone to fix the problems he knows he has, instead of being transparent and setting expectations based on facts.
An Amber status is often a bit of a cop-out. It says ‘I’m not 100% comfortable with how this project is looking at the moment, and I’m just covering my own rear in case things get worse.
And a Red? In some organisations, this is taken to mean the project manager and the team have major problems they cannot handle. In some cases this results in the project manager being replaced (for no reason other than honesty) instead of fixing the cause of the problem that led to the Red status being reported in the first place.
RAG status codes are more often than not ambiguous and interpreted differently by different people. So what do we do differently? Simple – report facts and leave out the subjective status codes. That way stakeholders have to hear the full picture. In Agile projects, there is no substitute for regular demonstrations of actual progress to stakeholders. And if some sort of regular status reporting is required, replace the RAG status with a graph – either a burndown (or CFD) chart of progress within the current iteration, or a bar graph showing work remaining (or completed) in each iteration. Or both.
There is nothing that a RAG status will convey that a graph of actual performance won’t convey better.