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
>Prio: HIGH
>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"
