Your developers have just planned a two week iteration. The next day Sarah continues her work on the completion of an important New Project. And here it comes – Urgent Stuff:
>From: Project Manager
>Sent: 2nd Day Of Iteration
>To: Sarah, the Developer
>Cc: Yo, Dev Manager
>Subject: Coarechon needs Ezhibal
> I need you guys to find out if we can add “ezhibal” functionality to our old “Tounaf” project, and how much time this fix is going to take. We have a hot deal with an important customer who is almost ready to buy.
> Sarah please investigate ASAP. We can arrange a phone call to clarify requirements.
Soon there is a dialog that might go like this:
Project Manager: “Sarah, how long do you think it takes to check if it is feasible to add this ‘ezhibal’ feature?”
Programmer: “Well, I don’t remember the old project details, but I can spend 2 hours to see if I can come up with something.”
Development manager: “Sarah has her iteration planned. Why don’t we stick to the plan?”
Project Manager: “What’s the problem? It just takes 2 hours! What harm can it do?”
“It just takes 2 hours. It can’t hurt!”
It can. We development managers learned it the hard way. We know how programmers think. We know how expensive switching their context is. If Sarah spends just two hours thinking of her old project, she loses a day of productive work on the new one. One day is 10% of a carefully planned iteration wasted if she spends 2 hours sidetracked.
In the wild nature of software development shops, however, it never takes 2 hours. 2 hours is the time Sarah is on the phone trying to clarify the problem. 2 hours is the time she is waiting for this phone call, reluctant to get into anything serious. 2 hours is the time Sarah is tweaking her development environment to build her old project. 2 hours is the time Sarah is spending to see if she can come up with a very restricted workaround. 2 hours is the time Sarah is on another phone call, explaining the potential workaround. Not enough time for real solution, no time spent on actually resolving the problem. 10 hours of unplanned and unproductive time is spread out over 3 days. 30% of iteration wasted.
At this point the planning goes down the toilet. The iteration is dead. The new project is slipping late. The rush around the old project yields little results either: with no time for a real solution the best bet there is a quick and dirty fix.
But the harm goes further. Sarah was eager to spend time on programming – she wasted it. She is robbed of her professional satisfaction, the good feeling of achieving the iteration goal and releasing project on time. On the next iteration planning session Sarah can’t help thinking “Why kill time if we don’t stick to the plan anyways?” The team gets the message: “We are NOT seriously doing iterative development. We are going ad-hoc”.
Here is what I do:
* Tell the developer to stick to the original plan. Offer to protect her from switching her mind context. Remind her how cool it is to work single-mindedly on an important and interesting project. Ensure her that I’ll handle the pressure. This is the good part; it is always well received 🙂
* Tell the project manager that the iteration is carefully planned with a goal to release the new project by expected date. The plan leaves no space for switching the context daily. Our options are:
1) Put the issue to the back log and plan it for the next iteration.
2) Cancel the iteration, suspend the “new project”, replan and work on the issue.
Let them make their call. This is the tough part; it is never well received. But I have to take a stand. I don’t have the luxury not to do this.
The iterative development is an act of fine balance between adopting the continuous change and securing some stability for the developers to perform. We as development managers are responsible for keeping this fine balance. We do it for our team. We do it for our project. And we do it for our fellow project managers.
Cause we know something they don’t always know: “How two hours can waste two weeks”
First published on SoftwareFrontier
It’s great to have all the visitors here from Reddit and Joel on Software – thanks!. Joel brings up a great question about the other side of this: what about the sales guy who wants the new feature?
8 thoughts on “How Two Hours Can Waste Two Weeks”
How Two Hours Can Waste Two Weeks
Dmitri Zimine posted an article today on Agile Advice about the effects of adding new, unplanned work to an already planned iteration. This is something I’ve had to deal with before, and I agree whole-heartedly about the disasterous, long-term effec
Scrum at Atalasoft: Dealing with Urgent Items
One of the problems in Scrum is what to do with new urgent items. There is an interesting discussion…
Is that the sort of pressure a development methodology should be placing on people, that having to reassign a resource for a single day is a cataclysm?
Context Switching on reddit
Programming.reddit isn’t a random link hub, but a community now. You can see this by the themes, which develop from time to time. One theme was "Context Switching".It started with the article How Two Hours Can Waste Two Weeks, which tells a st
Costs of Multitasking
Johanna Rothman is looking at the Costs of Multitasking and asks for suggestions both on other aspects of multitasking and on how to evaluate their impact (cost).
Agile – Rigid or Nimble?
From Dictionary.Com agâ€§ile /ËˆÃ¦dÊ’ É™l, -aÉªl/ Pronunciation Key – Show Spelled Pronunciation 1. quick and
Yes, I do call this Agile.
In his latest article, Joel Spolsky reacts to Dmitri Zimine