Red, Yellow, Green or RYG/RAG Reports: How They Hide the Truth

What is Red Yellow Green?

Red Yellow Green lightsRed-Yellow-Green (or Red/Amber/Green) is a status reporting mechanism used to help executives understand the current state of a project. Green means everything is good; we’re on track both with time and budget. In some cases, green means within 5% of budget. Yellow means there is some risk that there are scope or time problems, but with sufficient re-planning we can come back to target. Yellow is usually measured by some number crossing a predetermined threshold. Red indicates the project is in serious trouble.

Models

RYG is just a model of reality (in truth, all reporting simply models reality). All models hide details with the goal of making the situation easier to read and understand. Some are hidden so much that the truth gets lost.

A team’s Task Board, Scrum Wall, or the overall Portfolio Kanban Wall are all first-order models of reality. While not perfect mirrors of the current state of the work, they’re fairly close. They help demonstrate qualitative information; i.e. which stories are complete, not just how much.

A Release Burndown Chart, Burnup Chart or Cumulative Flow Diagram are all second-order models of reality. In other words, they summarize information contained on the Walls/Task Boards. They’re useful because they help spot trends. The Cumulative Flow Diagram provides the most information on trends, but it still has less information on it than the Portfolio Kanban.

Red Yellow Green Reports are models of the charts, in that they summarize the charts, hiding even more informational details. They assume that a plan’s scope, budget, and time are fixed and unchanging. Models might be adequate in a world where these are true, but in a world that accepts change as the norm, colour-coded reports are dangerous.

At best, these reports don’t measure truly done so much as whether a team is on track to make a target. In addition, since RYG reports usually have green as a default state, often there are too few questions that are asked until it’s too late.

Charts

Even burndowns, burnups, and cumulative flow diagrams are imperfect because they focus on output (# of Stories or story points achieved) and not outcomes (the right features delivered to the customer.)

Charts of all forms appear to promise certainty, when there isn’t any, which creates a false sense of security. If we’re going to chart at all, we should use forecasts and not precise lines, and make it clear this a forecast. If your chart just shows the average velocity, then you should provide a forecast that says we have a 50% chance of achieving this rate for the foreseeable future.

Red Amber Green - number of stories remaining chart

If you want to get more sophisticated, you can track error bars as well. Measure your best and worst three Sprint’s Velocity in the last six months, and use these as your 20% and 80% confidence bars. Then you can say that you’re 80% confident you will do at least as well as your worst three sprints, and 20% confident that you will do as well as your best three sprints.

Red Amber Green - confidence line graph

Even this model has a weakness in that it assumes your velocity will follow normal distributions. The reality is likely that it won’t. However, forecasting with error bars (or lines) usually gets the idea across that we’re forecasting a range of possible outcomes.

Genchi Genbutsu

Finally, all reports discourage people from leaving their offices. They give us the false feeling of safety. The report seems real and so it gives a good model of what is actually happening. Toyota has the practice of Genchi Genbutsu – go and see, literally. Review the charts but then leave your office and go to the place of the work. Watch, listen, ask, and review the Portfolio Kanban wall with the team(s). This will bring you back in contact with the reality of which features have been truly done. This will help you see if all the Story Points in the charts delivered the value that they claimed.

Stop/Do

So stop using RYG reports. They hide too much information. Do use Burndowns/Burnups/Cumulative Flow diagrams as a tool to help you spot trends, but don’t rely on them alone as the source of truth. And most importantly, review the Portfolio Kanban Wall with the Team(s) on a regular basis, as this is our best measure of reality.

http://www.drdobbs.com/dr-dobbs-agile-newsletter/191600661

Other have taken up on it as well:

http://www.solutionsiq.com/greenshifting-and-redshifting-within-projects/

http://www.edmundschweppe.com/2013/12/the-green-shifting-anti-pattern/

http://calleam.com/WTPF/?p=1205

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
145 City Rd
London
EC1V 1AZ
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.