Agile Lab Blog

I wanted to write today about the power of the Agile bad news bump.  I got this idea from an Agile Coach that I worked with at JP Morgan – Scott Bird.  Being an American and more comfortable with sports metaphors, he called this “The Agile Hockey Stick.”  The basic idea is that in an Agile Project, bad news shows up earlier than in a conventional project.  The more sophisticated idea is that the shape of bad news is different in an Agile project than it is in a conventional project.  But people who are unused to Agile projects assume that the shape of the bad news is the same.  And this is the main reason that they go crazy when they find out right at the beginning of the project that there is already trouble.

 

What causes the bad news bump in Agile projects?  Well, the bad news in an Agile project really happens when two important agile artefacts collide – the prioritised, effort-estimated backlog and velocity.  The effort estimated (preferably in terms of complexity points rather than the nightmare of ideal days)backlog is a catalogue of everything that needs to be done on the project.  But we don’t really get an idea of how long the project is going to take until we actually start to work on the backlog.  Once we do start to work on the backlog, what tends to happen is there is a very quick realisation that the project will take much longer than was initially estimated.  This alarms a lot of senior management.  They can’t believe that development has only been going for a few weeks and it is already in crisis. They are used to reporting from conventional projects, that is they are used to being lied to for almost the entire duration of a project, until the lie becomes untenable and the bad news finally leaks out.  Also, unconsciously, the think that this is still going to happen, that they are going to get bad news and then yet more bad news later. They tend not to understand that discussion about how long the project actually might take, based on data mean that the risks associated with the project are being addressed at a point where there is still time and resources to do something to correct them.

What should management and senior stakeholders do when they get this bad news  - that the project is about three times the size, or is going to take about three times as long as they thought it would? Well, before I get on to what they should do, let me just run through what they will do.

1) Deny it

As anyone who’s read their Elisabeth Kubler Ross will know – denial is the first stage of grief.  The first reaction of the bosses to early bad news about a project will almost inevitably be denial.  Yes, that’s right.  Given actual data to set against their pristine plan, they will believe the plan rather than the actual data.  Very often this will be coupled with requests for ridiculously detailed estimates of how long remaining work is going to take (in one extreme case, I had requests for estimates down to the minute).  This is a real danger point.

2) Get annoyed/accusatory (anger)

“I thought I hired professionals who knew what they were doing.”  Well, if you understand the nature of the Cynefin framework, and which quadrant software development sits, you’ll understand that the people who do software development aren’t professionals. But this attack has power.  Again this is a real danger point.  Especially if it’s framed as “Well, if you can’t do it, maybe I’ll have to find someone who can.”

3) Bargaining

Bargaining can be a good stage.  It can be a disaster.  What you want to be bargaining about is scope.  You want to get an agreement from the bosses that it’s OK to deliver a reduced amount of high-value, high-priority scope in a reasonable amount of time.  What you absolutely don’t want to agree to is any “solution” which involves your teams working late, or working weekends, or in any other way “trying harder.” Trying harder simply isn’t a strategy, it isn’t even a tactic.

You also want to avoid any kind of double-counting or arithmetical tricks.  This is amazingly common. A popular tactic at this point is to split the development team in two – and then “plan” to give each team the same amount of work as the original team.  Another, more subtle, but equally useless tactic, is to “share” key team resources across several projects.  This is an area where spread sheets are a menace.  It’s just too easy for someone more in love with plans than real data about actual progress, to shave, round, leave out and double-count until the “numbers look right.”

4) Depression

“This is going to upset a lot of people. We’re going to look bad.  This is going to be very embarrassing for the company. Is that what you want? ”  Nobody wants that.  Everybody is trying to do a good job, to the best of their abilities.  This is another danger point.  Everybody wants to show willing.  Nobody wants to be a naysayer.  It’s very tempting at this stage to say something like “well, we’ll try our best.”  What else were you going to try?  Your second best? If you do say something like that, what the bosses will actually hear is “forget what we said about this project taking three times as long as you thought, we’ll simply do it all for when you want it.”

This admission that the real reason they’re being so difficult is that THEY are going to have to have an awkward difficult conversation is actually the opening that you need to get a decent bargain.  Which bits of functionality would be enough to save face/avoid embarrassment/stop the stock price from plunging?  Let’s agree to do those first as a priority.

5) Acceptance

This is where you’re headed.  You hope.  The one thing that you have on your side is that you are actually collecting the figures that show genuine progress through the backlog.  If you get denial initially, you can wait an iteration and then point out the realities again.  This is why it’s so important to resist any attempts by the bosses to manoeuvre you into promising something that you know to be impossible.

Pushing through or over the Agile bad news bump can be a hairy experience. It can feel a lot like white water rafting.  A properly turbulent experience where neither you, nor your bosses know which way is up.  If you’re doing your job well, you’d be delivering good news to the bosses wouldn’t you?

But the Agile bad news bump, can, if handled well, actually be a powerful method of aligning senior management and stakeholders.  Negotiating bad news this early in a project does one of two things – it either kills the project, or makes it stronger. The bosses and teams that are actually doing the work, to one single view of where the project is and where it’s going.

Obviously what you’re hoping for eventually is for the bumps to get smaller.  And if you start to put similar work in the same problem space through a mature team they will do.  They won’t go away altogether.