Hello again,
like many of us I’ve come across projects or organisations using RAG (Red, Amber, Green) reporting as a process overlaid on development teams using Agile methodologies. Typically this is so that leadership, or some kind of governance committee can get a top level view on the status of a particular project, its components and ideally provide help when it’s needed to ‘de-risk’ progress.
Unfortunately, more often than not, everything starts out GREEN, turns to AMBER for the majority of the time, followed by a panic RED just as the various stakeholders realise they are well and truly up ‘shit creek’. Asking for help in high pressure projects, especially those involving transformation, or Wagile (waterfall Agile) means many stakeholders have a reticence to wave the red flag for fear of the spotlight. It’s also very difficult to summarise complexity, into a subjective single colour status.
The below is an interesting read on RAG, and reaffirms my feelings on the very questionable use of this relic for ‘Agile’ projects.
RAG – What are you really measuring?
Original post by aterny
“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. I recently spoke to a Head of PMO who said she uses the term Watermelon Green to refer to projects which are Green on the outside and Red when you open them up and look inside.
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. The same Head of PMO calls this Institutional Amber, so prevalent is this.
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, although I know of one company that created a formula based on cost, milestone and other measures to derive a RAG status. Interestingly, the validation allowed a project manager to override the status upwards, but only a Sponsor could downgrade it.
But it’s still a lot of nonsense to accomplish something really simple – understand whether a project is on track or not.
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 aburndown (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.”