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!

Value stream mapping -- new or old?

---

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the "old days", we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

De-clutter!
Some call it "de-cluttering". Don't hang onto the stuff you really aren't going to use.

And, of course de-cluttering the non-value add begs the question: what is value-add?

There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put:  

Anything that is ultimately delivered to the customer, or contributes to making the customer deliverable a good thing in the customer's eyes; anything that makes the customer more successful; and anything that gives the customer the willingness and capacity to pay.

A lot of project and business stuff would not fit this definition directly. Nevertheless, most practical organizations can't live without them, so there's a certain non-value overhead that goes along with everything.

Clarity of diagramming
One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

---

Buy them at any online book retailer!

Who said 'hybrid Agile'?

---

What's the hybrid thing?
It's agile coexisting in the same project with a traditional methodology, presumably for the swim lanes that are not software.
Some call hybrid agile as: agile in the waterfall

Are hybrids practical? After all, the traditional is top down planned, most requirements up front, much system testing at the end, etc. Agile is the not-traditional. Can you fashion a hybrid out of these two?

Actually, hybrids are very practical, if one internalizes the "hybrid operating principle"

Hybrid Operating principle

Agile projects are simultaneously strategically stationary and tactically iterative and emergent

I mean by “strategically stationary” that:

• Whenever and wherever you look, the project has the same strategic intent and predictable business outlook.
• Strategically stationary is not unique to agile, of course -- traditional methods actually impose stationariness, and business planners do also.  

Strategic intent is what is expressed by the business for the opportunity and vision of the project.
Strategically predictable business outlook is the outcome that is expected of the project, typically expressed as the mission, but also found on the business scorecard.

I mean by tactically iterative and emergent that:

• Flexibility is delegated to development teams to solve issues locally;
• Teams are empowered to respond to the fine details of customer demand while respecting strategic intent in all respects; and
• Teams are expected to evolve processes in order to be lean, efficient, and frictionless in development.

And this all leads where?
The overlay of strategy with tactics

The upshot of a tactically emergent and iterative risk response is that we may find that actions in the moment are a seeming variance to the strategy—that is, the project plan. But, over time, we may take other actions that converge on the strategy. In effect, we overlay the strategy with tactical expediency at the moment.

What are these actions?

For the Agile work stream, the most common tactical move is adjustment of the iteration backlog, the repository of “stories” or use cases that are the gist of requirements in the Agile methodology. 

Another form of tactical maneuvering is the result of technical or functional debt: those small items which have been left behind on a “punch list” to be completed before the project ends.

And why are these actions taken?

Most commonly, because the customer/user sees a better way to achieve a functionality; sees an unnecessary story that can be dropped; or has been given information about a requirement, heretofore unidentified, that should be added to the backlog.

These debt may cause small changes which may seem to lead off the strategy, but more often they help to converge to the strategic intent.

---

Buy them at any online book retailer!

Unintended consequences of metrics

---

In the online "Cross Talk -- Journal of Defense Software Engineering" for Sept Oct 2016 there is a an article entitled "Positive Influences and Unintended Consequences" by Rob Ashmore and Mike Standish of the U.K. Defence Science and Technology Laboratory

On the general topic of metrics, they make the point that generally all metrics have unintended consequences. (No news there; I think we can all agree with that. In my parlance: For every measure, there is a counter-measure. To which there is a counter-counter measure .... ) And to make their case, they cite observations by other researchers of U.K. public sector organizations that the consequences can be grouped into eight distinct types:

• Tunnel vision, when management focuses on quantified aspects of performance rather than overall quality.
• Sub-optimization, where narrow, local objectives are prioritized over the wider objectives of the organization as a whole.
• Myopia, which involves the pursuit of short-term targets at the expense of legitimate long-term objectives or outcomes.
• Measure fixation, where managers focus on the metric, rather than the objective for which the metric was developed.
• Misrepresentation, where the reported metrics do not match the behavior on the ground.
• Misinterpretation, where those to whom the metrics are reported make incorrect or inappropriate decisions.
• Gaming, where behavior is deliberately altered so as to exploit loopholes in the measurement system.
• Ossification, where an overly rigid measurement system prevents innovation.

To combat these phenomenon they introduce and explain a tool which is really just a cause-effect diagram that closes on itself -- closed loop. A "causal circle" of sorts. Read the article for more detail.

 I can't fault them on that idea. I've been preaching for years that closed loop systems are the only stable systems, and that goes for communications generally, measurements specifically.

---

Buy them at any online book retailer!