Apr

Signal to Noise Ratio of Delays

Eli Lopian Category

Travis, has made some excellent points again, talking about the Signal to Noise Ratio of the ‘delay event raising’.

I have had this problem from a different angle. When asking some employees for their daily/weekly commitments, some employees take the task breakdown too far and have a really long list of stuff that they commit to. Its is normally a long long list full of small tasks.

For Example, Lets take a team who has a weekly commitment to validate the Disaster Recovery Program (along with other commitments)
On Tuesday standup one employee says that he intends to:

Unpack a new detachable disk
Plug it on the network
Ask IT to help configure it
Run a backup
Install a new restore VM
Run a restore on another machine
Validate the restore VM

This is fine and it is a good way to manage oneself, but the team doesn’t really have to know about this, is such detail.

Group the items

The manager/team at this point should say: Ok, lets group that. So you intend to:

Verify that the SVN backup works.

That person can (and probably should) make the list for himself, so that if he sees that he is not going to fulfill his commitment, he can tell the team

I will finish the backup only by tomorrow noon

At which the team might find a way to complete its weekly tasks anyway, and no event goes up the stream, or they might have to tell management about the new time table.

When raising the event use the grouped task

The commitment to management was validate the Disaster Recovery Program this week. If the team can still do it, so there is no need to tell management. If they can’t, they say:

We won’t finish the DRP validation, this week, it will be done by Monday Evening.

Here management doesn’t get the noise but get the status of the tasks without needing to go to any meetings at all. At this point the manager will try help solve the delay.

In the chart above the tasks are broken as we go right, When a delay event is risen the tasks are grouped as we go left.

If we manage to solve it (above), all is fine, if not (below) management can make the right choices as it knows exactly what the status is.

No need to wait till the end of an iteration to know where we stand and no need to go to standup meeting of all the teams.

2 Comments to “Signal to Noise Ratio of Delays”

Travis Illig April 3, 2009 at 5:34 pm
This is exactly how it works for us, with the event bubbling.

We, too, face the issue where some folks like to report on every tiny granular task. Every month or so we have to give folks a “friendly reminder” that we don’t all need to know every tiny detail, just tell us the net of the tasks.

Some folks don’t get it and very quickly return to reporting granular lists of tasks – not “I fixed this bug yesterday” but “I went and talked to this person, who then pointed me in this direction, and then I set up this test to replicate the issue, and then…” That sort of report is even noise to the rest of the team.
Eli Lopian April 3, 2009 at 8:00 pm
Great,
Do your managers also get the ‘delay events’ – on time? That is not at the end of the iteration, but at a point that they can help. Do they have to be in the stand-ups to get that information?