Last week at the Agile Open Space in Toronto my friend Andrew Annett suggested we should start all projects red. I’ve been thinking about this concept all week and I think it’s brilliant! There are pitfalls with this approach, but it accurately portrays the current state … no plan, high risk, and lots to learn! To say you’re green is just creating a false sense of security!
If you’re not familiar with the colour reference it’s a commonly used semaphore to show the health of a project. I’ve seen different definitions but generally green means you’re on track, yellow means you have some leading indicators of problems, and red means you have fallen off the rails. If you’re red there are elements of your plans which are no longer valid.
So when you look at these definitions why do we declare ourselves green at the start of a project? The reality is we don’t have a plan, we don’t know what risks lay in wait for us, and the project definitely needs attention. Often I see unfounded optimism at the start leading everyone to believe we’ll do it right this time (see my post on optimism).
Whether it’s the start or middle of a project there is only one critical activity the team needs to do when they go red … Learn! To move away from the red status I would propose the project team needs to learn about their biggest risk then respond to it. We often hear the right thing to do on a project is to address the biggest and most difficult risk first. After all it’s better to find out your project isn’t achievable right from the start isn’t it? Once you’ve moved that risk aside perhaps then you can move yellow. Once you address the next risk then maybe you can turn to green.
The downside and politics
During the Agile Open Space I tweeted the thought of starting red then learning yourself towards green. Within minutes someone replied with:
“Much like the France criminal law.. Guilty until proven innocent!”
The underlying problem with this idea stands out in that simple reply. Red is too often associated with bad things, failure or finding the guilty! I’m not suggesting we should celebrate being red, but I do think cultures should encourage honest and transparent reporting. The team needs to learn to work their way back towards green. Management needs to pay attention. If organizations don’t pay attention to red projects you may as well terminate the project as you’re only wasting money!
One of the arguments I heard against the concept is people will become numb with too much red (ie. they stop paying attention). This is a cultural problem! In one of my engagements they became concerned if you stayed green. If you were green for more than 4 weeks you were called in to explain why things are going so good. Given the nature of software development it’s nearly impossible for things to go so good for so long. In doing this they made it acceptable to make issues visible by turning your project yellow or red. It was one of the best environments I’ve worked in.
I’ve always believed there’s no room for politics in the reporting of colour on a project status. Unfortunately this will be an up-hill battle as people just don’t want to publicly declare things are not going well. Until this corporate culture changes we will con
tinue to hear of embarrassing statistics of failed projects.
I am already looking for the opportunity to help an organization by turning all the virgin projects red at the start! This is a brilliant concept and accurately conveys the status of a project when you’re getting it off the ground. Anyone who tries to tell me they’re green at the start will have to show me proof from now on
I’d like to hear your thoughts! Please comment!
+1 Mike – totally agree. While consulting at Microsoft we used traffic signal score cards everywhere – and they all started green. Within a about 2-3 weeks, they would invariably go yellow, then red as we discovered more about the customer’s problem domain. I even had the charade of starting out saying “everything’s fine” called out by some astute customers.
While it may seem pessimistic, I think it better to say we need to earn our way into green rather than presuming it to be the status quo from day zero when we are the most ignorant about the system we’re trying to design.
I wish I’d seen Andrew’s talk – it sounded like an excellent discussion. I think this concept can be very powerful if it sparks discussions about potential risks and tradeoffs that traditionally are not discussed until late in the project when options are limited. I have used these types of conversations as a driver for introducing incremental development in the past.
A potential pitfall to be mindful of: I’ve seen a few projects that declared themselves “red” on day 1 (often due to a perceived time crunch). This led to their teams being (or feeling) pressured to get to “green” as quickly as possible – at all costs. This caused panic – and result in death spiral practices such as regular overtime, cutting corners and abandoning improvements, leading to a mountain of technical debt generated in record time. As you can imagine, these projects rarely get to green.
Ironically, these groups see “red” as meaning we must go faster (over a cliff?), rather than, as Mike put it nicely – “elements of your plans are no longer valid.” This illustrates one of the many reasons I’m not fond of RGYP – they have so many different meanings to different people, and how to respond to them is equally up for interpretation. RGYP aside, this appears to be a powerful mindset tool for encouraging groups to have the difficult conversations upfront.