Wednesday, February 6, 2019

Burning up the team


Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

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 you suggest lend objectivity to the process (not playing favorites, etc).

Losing productivity
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.

Brook's Law -- it's not been repealed
Other observers have put it down as "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . Read: "Mythical Man-month" for more from Brooks

Did I mention Physics?
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.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference.
Many have told me: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
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. The problem arises with sponsors: their answer is universally: throw more resources in, exactly opposite the correct remedy

6x2x1, or other
One of my students said this: "Daniel Pink  has an excellent book called "Drive: The surprising truth about what motivates us" that 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."

And now, we rest!



Buy them at any online book retailer!

No comments:

Post a Comment