Remember the first time your son or daughter held a helium balloon in his hand? What happened? Sooner or later, that balloon got away and s/he was very unhappy, to say the least. One might even say, traumatized. Why? Because s/he lost the balloon? That’s certainly part of the answer, but it’s not the whole story — kids lose things all the time, without the emotional trauma of that first balloon.
That balloon’s flying away contradicted “years” of experimental evidence (generally obtained using food from the kitchen table) that things always fall down. Always. Dependably. Reliably. Certainly. Despite this certainty, that balloon fell up. The world is not in order. And that is what was so disturbing.
So you have just started using Scrum to manage your first development project. You have 6 months to complete the project. The remaining effort on your project is estimated to be 600 Story Points (SP), which means you have to complete 100 Story Points per month. So far, so good.
Then your team executes its first Sprint and completes 50 Story Points. At this rate, it will take 12 months to finish the project ( 600 SP / 50 SP per Month = 12 Months). So you tell your boss you have a problem, you’re going to be 6 months late, on a six month project. What does you boss do?
- Kill the messenger (what else?)
- If that fails, blame the methodology (which is kind of the same thing).
Why is he reacting this way? For him, a balloon is falling up. Typically, early in a project, everyone is optimistic.Serious problems only become apparent later in the project, shortly before a major development milestone. So when a deadline problem escalates, it is serious and doesn’t leave much room to maneuver.
BTW — yes, I have had the pleasure of taking over a project in which the program manager had invested a large sum, only to be told shortly before the target date that it will cost another equally large sum to finish the project. Bad thing. No fun for anybody involved. And the program manager really only had two alternatives: Cough up the money or cancel the project. Either way, he had to explain it to his management (and is not going to look good in the process).
Come back to our Scrum example. Probably this program manager had never gotten such early warning that project was having problems. So how is he going to react? Exactly as he has been conditioned to through every other project that has been late, only more so, because if a warning occurs this early, something must be seriously wrong.
But wait! Only 1 month has gone by. The are still 5 months to go. You can react. You can identify the problem and make adjustments. Why is the development proceeding so slowly? Are there enough people? Are they the right people? Maybe you can reduce the scope and still achieve your business goals. Maybe your developers are being distracted by other tasks. There are a lot of ways to fix a project with over 80% of the time remaining.
Together with the Product Owner, the Scrum Master and other management can take action to correct the problem early and effectively.
Once management has learned that they have control, can react and can prevent disaster long before it occurs, they will no longer be tempted to kill the messenger. In fact, they will welcome the messenger and appreciate the methodology, because early warnings will ensure that management looks good when the project comes to a successful and timely conclusion.