Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan
Formula solution
Google
among others -- Microsoft, etc -- are well known for the "time off, do
what you want toward self improvement and personnel innovation" model;
formulas like that lend objectivity to the process (not playing
favorites, etc). Note: more on this in the "6x2x1" model discussed last
Productivity drop
Of course, the real issue is one that
agile leader Scott Ambler has talked about: the precipitous drop in
productivity once you
reach about 70% throughput capacity of the team.
Up to this point, the pace of output (velocity) is predictably close to
team benchmarks; thereafter, it has been observed to fall off a cliff.
Other
observers have put it down as a variation on "Brooks Law" named after famed IBM-370
project leader Fred Brooks: "Adding people to a late project makes it
later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!
Wave bounces
In
the physics of wave theory, we see the same phenomenon: when the "load"
can not absorb the energy applied, the excess is reflected back,
causing interference and setting up standing waves. This occurs in
electronic cables, but it also happens on the beach, and in traffic.
Ever
wondered why you are stopped in traffic miles from the interference
while others up ahead are moving? Answer: traffic load exceeds the
highway's ability to absorb the oncoming cars, thereby launching
reflections of standing waves that ebb and crest.
So
it is in teams: apply energy beyond the team's ability to absorb and
you simply get reflected interference. Like I said: the way to
speed things up is to reduce the number of teams working and the number
of staff applied.
In
agile/lean Kanban theory, this
means getting a grip on the WIP limits... you simply can't have too many
things in play beyond a certain capacity.
Sometimes the
problem arises with
sponsors: their answer is universally:
Throw more resources in, exactly
opposite the correct remedy
6x2x1 model
One of my students said
this:
"Daniel Pink has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks
about inspiring high productivity and maintaining a sustainable pace.
One of the techniques is the 6x2x1 iteration model. This says that for
every six two week iterations the development team should have a 1 week
iteration where they are free to work project related issues of their
choice.
You can also run a 3x4x1 model for four week
iterations. Proponents of this approach have observed that the
development teams will often tackle tough problems, implement
significant improvements and generally advance the project during these
free play periods. Without the time crunch to complete the story points
the team also refreshes itself."
I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!
Read my contribution to the Flashblog
