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!