Approaching team burnout

---

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.

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.

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!

---

Buy them at any online book retailer!

Mistakes? What, me?

---

Some say that an enlightened business/agency/enterprise is one that provides the freedom to make mistakes. Quantmleap had a posting on this very topic.

Perhaps... But, I don't agree with the broad idea that we need to allow for and accept mistakes. Mistakes are only tolerated up to some point, then ....

OPM
If you're working your own money, then you're free to make mistakes. But, if you're working with other people's money (OPM) it's all together a different situation.

Take a risk
This idea about mistakes should be more narrowly drawn, to wit: we need the latitude to take risks --some of which may not work out -- that are within the risk tolerance of the enterprise. How do we know what the tolerance limits are? We can ask, or by experience and intuition we learn/know the boundaries.

Risk evolves
Here's the tricky part: risk attitude is not stationary: it matters when you look at it. Over time, optimism abates; pessimism rises. And, prospect theory tells us that risk attitude is different if you are facing a choice between bad or worse or between good or better.

So, it matters when the mistake is made (temporal dependency) and matters whether or not a mistake was made trying to avoid a really bad outcome (utility dependency)

We also need the latitude to make tactical errors (mistakes in some cases or calculated risks in others) so long as we don't make a strategic error. That is, we can be wrong tactically so long as we can recover and get back on a track toward the strategic objective. But to make a mistake on the strategic objective is almost always fatal.

Causality
We should also be mindful that -- even with the latitude allowed for these classes of mistakes or errors in assessment or even judgment or risks gone bad -- the cause or causality of the mistake is material. Negligence will never be tolerated; so also duplicity, though innocent ignorance may be ok.  Thus, the same mistake (effect) with different cause may be tolerable, or even thought to be a good bet that didn't work out.

Absolute?
Consequently, as in all 'rights', the right to make a mistake is not absolute;  as a practical matter there are often many constraints to even a liberal degree of latitude.

---

Buy them at any online book retailer!

Getting it done

---

"Others may have plans; I have deadlines"

Amy Klobuchar

 Senator

This sentiment has been expressed in other forms, most famously by many:

• Plans don't survive first touch with reality
• Plans are nothing; planning is everything

The big idea:
Plans are the process; outcomes are the value.

Manage with milestones
Detail planning is good -- it brings out the interdependencies and sequencing demands. But such attention to detail is inefficient, even counter-productive during execution. Much more better in my experience to manage to milestones, which is, in effect, "managing to deadlines".
 
The point of projects is to create value. 
Ultimately, the plan is project detritus; the outcome is the only lasting memorial to success

---

Buy them at any online book retailer!

Think for yourself?

---

"Don't take a [drink of] the Kool-Aid when you don't know the flavor"

Cory Booker

Senator

In other words:
You may like what you hear; just be sure you understand what it is you like

---

Buy them at any online book retailer!

Project narrative

---

Agile leans heavily on the idea of "the narrative" or "epoch"; other methodologies speak of strategic outcomes and value statements. In any form there is the inference of "the" narrative, as though there is only one arching aiming point for the project.

Not so fast!
Not all might agree; alas, there might be (are you ready for this?) disagreements regarding the value statement, narrative, or needed outcomes

"But seeing our disagreements through the lens of narrative might get us closer to a crucial insight -- which is that in a big, diverse, and complicated [project], multiple narratives can be true all at once"

Ross Douthat
Political observer

Likely true, but what do we do with it? 
For one thing, if the word "narrative" is understood to be "agenda" in some circumstances, then the first thing to do is to separate the "agenda narratives" which are largely political from the "functional narratives" which are more traditionally aligned with the scope-resource-schedule-quality drivers.

Each narrative class has its own (balanced) scorecard and project balance sheet: outcomes balanced by resource and risk

Who's in charge?
In the beginning ....
In the beginning, the agenda (read: political) narratives may be supreme:

• Buy America first
• Buy best value, or buy best price?
• Be first!
• Be dominant

 But then there are the project practicalities that push against the political agenda:

• Buy America? You can't get them here: Most essential rare-earth minerals come from abroad, and most from China
• Price? "My only concern is that this system was built by the lowest bidder" Astronaut
• First is best? See: Netscape (the business model didn't work in the long term)
• Dominance, but not at the expense of nimble (Netflix vs Blockbuster, both originally in the CD business)

Your role?
All of the above: politician (to get things rolling), and project manager (to make sure the roll is successful).
And "you" may be a small team; it's rare to get a supremely good politician and manager in the same package (See  "Ike" Eisenhower and George Marshall two of the best politician-managers)

---

Buy them at any online book retailer!

Against the Gods .... (no luck required)

---

If you are in the project management (read: risk management) business, one of the best books that describes the philosophy and foundation for modern risk management is Bernstein's "Against the Gods: the remarkable story of risk".

Between the covers of this "must read" we learn this bit:

The essence of risk management lies in maximizing the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and the linkage between effect and cause is hidden from us.

Peter Bernstein

"Against the Gods: The Remarkable Story of Risk"

Knowledge and control
Picking apart Bernstein's "essence" separates matters into control and knowledge:

• We know about it, and can fashion controls for it
• We know about it, and we can't do much about it, even if we understand cause and effect
• We know about it, but we don't understand the elements of cause and effect, and so we're pretty much at a loss.

Of course, Donald Rumsfeld, in 2002, may have put it more famously:

" ....... because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know."

No luck
So there is an ah-hah moment here: if all things have a cause and effect, even if they are hidden, there is no such thing as luck. (Newtonian physics to the rescue once again)

Thus, as a risk management regimen, we don't have to be concerned with managing luck! That's probably a good thing (Ooops, as luck may have it, if our project is about the subatomic level, then the randomness of quantum physics is in charge. Thus: luck?)

Indeed, our good friend Laplace, a French mathematician of some renown, said this:

Present events are connected with preceding ones by a tie based upon the evident principle that a thing cannot occur without a cause that produces it. . . .
All events, even those which on account of their insignificance do not seem to follow the great laws of nature, are a result of it just as necessarily as the revolutions of the sun.

---

Buy them at any online book retailer!

After that, we had systems!

---

I was reading Matthew Squair's course materials on System Safety Fundamentals when I came across this slide:

"Life was simple before World War II. After that, we had systems."
Rear Admiral Grace Hopper (USN)

You've got to smile at that witticism!

The Admiral Dr (*), of course, is credited with leading the team that developed the first linking complier that led directly to COBOL.

But she had a fierce wit
Perhaps she is best known for inventing the system "bug" when she literally found a dead bug in in an inoperative computer system.(**) She retired from the Navy at age 79 in 1986 after serving about 50 years.

About risk, she is quoted "Ships are safest in port, but that is not what ships are built for"

And, of course, she is famous for demonstrasting that a nanosecond is the time taken for electrical signals to travel about a foot. She was known to carry a bundle of 'foot-long' "nanoseconds" to her classes in computer science. Watch here for her demo.

 ++++++++++++++
(*) PhD, Yale, '34 Mathematics
(**) a mix of lore and truth

---

Buy them at any online book retailer!