Interrupts
One of the potential risks of wasting time is Interrupts. In Evo, we only work on planned tasks,
never on undefined tasks. In case a new task (or a new requirement) suddenly appears in the middle
of a Task Cycle, we call this an Interrupt.
Assume the boss comes in and asks us to paint the fence. We don't say Yes,
but we also don't say No. After all, painting the fence may be more important
than anything we have currently planned, if an important customer would turn his heels
when he sees the shabby fence. Instead, we follow the Interrupt Procedure:
- Define the expected Results of the new Task properly. What is the actual risk that the shabby
fence causes trouble? Should we thoroughly grind, ground and paint the fence,
or buy a new fence that doesn't need paint, or just put a quick layer on the old fence,
just covering the dirt?
- Estimate the time needed to perform the new Task, to the level of detail really needed
- Go to the task planning tool (many Evo projects use the ETA
- Evo Task Administrator tool).
- Decide which of the planned Tasks have to be sacrificed
(up to the number of hours needed for the new Task)
- Weigh the priorities of the new Task against the Task(s) to be sacrificed
- Decide which is more important
- If the new Task is more important: replan accordingly
- If the new Task is not more important, then do not replan and do not work on the new Task.
Of course the new Task may be added to the Candidate Task list, to be considered later
- Now we are still working on Planned Tasks
But if we do the new thing in between, isn't this delaying the work we originally planned? Yes, of course it is.
But we deal with the consequences of the change in the plan. We Act.
If something comes
in between (see figure), the rest moves accordingly.
This appears difficult to understand for some people.
When a service-desk manager said: "If a customer needs service, the developers should drop their work and immediately help the customer."
I said: "OK. But that means that the rest of their work will move."
"That's impossible. The schedule shouldn't move!" he said.
I replied: "Whether we like it or not, it will move. We better acknowlegde that and see
what we can do about it." This event actually made me make this figure.
We don't let things happen
randomly, we rather
control how they happen.
If some requirements become more important than others, the order of what we do should change.
Priorities do change all the time, so the thing is to dynamically reprioritize as needed.
Revisiting
TimeLine will tell us what the consequences will
be: What will be done, what will
not be done, and what
may be done at any FatalDate.
We cannot do more than we can do.
We don't try to do the impossible. All we can do is making sure that looking back we always rightfully can say: "Nobody could have done it better. Not even us!"
With the Interrupt procedure, we control the risk of wasting time
on seemingly important things, as Interrupts often seem more important than they really are.
One of the Magic Questions is
"Who is waiting for it?"
If you don't get a satisfactory answer, then suggest that you apparently don't have to do it.
Saving time isn't that difficult !
