Agile in the critical systems space

---

I read a recent posting about agile from a very odd corner of the PM space for an agile conversation to be: CriticalUncertainties, a (conservative) blog about critical safety and failure (or fail safe) requirements in complex systems.

But, nonetheless, we get this input from critical systems safety expert Mathew Squair:

When you don’t know what to do, don’t sit down and plan what you don’t know, get people moving, talking, collaborating and making stuff. Then out of that activity you’ll find the information will emerge that will allow you to make decisions......

As Tom Peters points out we need to understand whether our methodologies have an inherent bias for action or a bias for planning, and then whether the situation is complex (but understood and stable) where planning will pay off or uncertain (with high novelty and volatility) where talking, thinking and looking at the small grain issues to build a picture of where we are is what we ought to be doing.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Understanding project statistics

---

Chapter 14 from the GAO Cost Estimating Manual on "Cost Risk and Uncertainty" is a good read, easily understood, and very practical in its examples.

Here's one illustration that I particularly like.  When you look at it, it's understood in a moment that the repeated random throw of two dice generates a probability density function [PDF] that has a bell-shape curve.

Statisticians call this phenomenon the Central Limit Theorem: random occurrences over a large population tend to wash out the asymmetry and uniformness of individual events, such that a "central tendency" occurs around the more probable outcomes.  A more 'natural' distribution ensues.  The name for this somewhat natural distribution is the Normal distribution, more commonly: the bell curve.

Here's what it looks like to a project manager.  
Regardless of the distribution risks in either cost or schedule as adopted by work package managers for each individual work package, in the bigger picture at the summation will tend to be a bell-shaped distribution of risk.

Consequently,  the project manager's doesn't really need to understand the parameters of variation for each work package. The Central Limit Theorem does all the work. Triangles, Rayleighs, and even Binominal distributions are become bell shaped in the big picture.

  This diagram is (again) from Chapter 14 of GAO's manual:

If the risk analyst generates these data from a simulation, like a Monte Carlo simulation, then the numeric statistics like variance and standard deviation are usually reported, along with the cumulative probability more commonly called the "S" curve.  In the diagram, on the right side, we see the cumulative curve plotted and labeled on the vertical axis as the confidence level.  With a little inspection, you will realize that the cumulative curve is just the summation of the probabilities of the bell curve that is adjacent on the left.

The GAO manual, and especially Chapter 14, has a lot more information that is well explained.  Give it a read.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Adding staff -- slowly

---

First, we have "Brooks Law", as given in the classic case study "The Mystical Manmonth" by Dr. Fred Brooks:

"Adding staff to a late project makes it later"

I was no more thinking about that idea, than I read this missive in a history of the Civil War that I am engaged with:

“The veterans looked across the open ground at the newcomers with complete and unconcealed skepticism and hostility. In every line of their bearing—in the set of their jaws, the tilt of their heads, the look about their eyes peering out from under those valued hatbrims—they expressed for all to see the age-old, impersonal, unformulated feeling of the veteran for the recruit:

We have had it and you have not, and until you have been where we have been and have done what we have done we do not admit you to any kind of fellowship.”

Excerpt From: Catton, Bruce. “Glory Road.” This material may be protected by copyright.

OK, that might be tougher than the normal project team might be, but in my experience, until there is bonding over a common stress, there's not cohesion, and maybe not even functional integration.

So, as in war and most other things, to speed assimilation along, sometimes a bonding experience is needed. Thus, all the bonding games, etc, but it often works. Else, just put everybody in the deep end. Survival will do all that is necessary

And, did I mention virtual teams: there's really not a difference, not really.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

5 levels of Agile planning ... and the DoD

---

Some years ago I picked up this nice summary image of agile planning over several time cycles. It came from a white paper at AgileConnection.com " entitled "Scaling Agile Processes: Five Levels of Planning

Fortunately, to give some credibility to his thesis, the author says right up front that agile methods don't scale to enterprise level without some changes!  He is so right. Since 2014 when the paper was written, SAFe (Scaled Agile Framework) and other scaling methodologies have come along and acquired creds in the community

So, as agile has matured, acquired some common sense, and worked its way into mainstream project protocols,  even large scale organizations, like DoD, have embraced some tenants of agile methods.

You can check out some of the references to DoD practises I've gathered from Glen Alleman and others. As well, read some background in the white paper I wrote "back in the beginning" about agile in the DoD.

• Handbook for Implementing Agile in Department of Defense Information Technology Acquisition
• Defense Agile Acquisition Guide
•  Considerations for Use Agile DOD Acquisition
• Agile Methods: Selected DoD Management and Acquisition Concerns
• Thinking about Agile in the DOD  
• DOD Agile Adoption

 Or, you can take a look at one of DoD's software journals, "Crosstalk" and search the journal for 'agile'

Better yet, give a read to "Project Management the Agile Way: Making it work in the enterprise, 2nd Edition"

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Terminator conundrum

---

There's some buzz about the DARPA program to develop autonomous sensors and weapons (potentially) that are AI driven but rely on relatively inexpensive platforms.

Here's what Robert O. Work, Deputy Defense Secretary is quoted as having said:

You could “use the tactical ingenuity of the computer to improve the strategic ingenuity of the human,”

Authors Matthew Rosenberg and John Markoff write that ... "Work believes a lesson learned in [AI applied to ] chess can be applied to the battlefield, and he envisions a military supercharged by artificial intelligence. Brilliant computers would transform ordinary commanders into master tacticians."

Hmmm, does that mean that brilliant computers (a.k.a AI) can turn ordinary PM's into masterful tacticians, following along with their business' strategy?
It's a concept!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The verification game, or gaming verification

---

At Critical Uncertainties I read a post that I hope is meant in the best of humor, but actually it might be quite serious

Here's the setup:

• Customer states requirement
• Customer states requirement verification protocol
• Project team implements protocol
• But wait ... protocol is only statistically applicable

And here's what Critical Uncertainties writes:

".... one realises [SIC] that requirements are 'operationally' defined by their associated method of verification. ..... Now if you're in luck ..... you propose adopting a statistical proof (because it's such a tough requirement and/or there's variability in the process, weasel weasel) of compliance based on the median of a sample of tests.
Using the median is important as it's more resistant to outlier values, which is what we want to obfuscate (obviously).
As the method of verification defines the requirement all of a sudden you've taken the customer's deterministic requirement and turned it into a weaker probabilistic one."

This last thing is the key and merits repeating:

"As the method of verification defines the requirement all of a sudden you've taken the customer's deterministic requirement and turned it into a weaker probabilistic one."

OMG! Did you pull one off on the customer, or did you simply introduce the customer to the realism of the verification protocol?

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

You say, but I say ...

---

You say: Value!
I say: Cost

You say: Balanced scorecard -- customer, organization, product, finance
I say: Cost, schedule, scope, quality

You say: Vision -- the long view
I say: Requirements

You say: strategy and strategic alignment
I say: tactics to overcome problems

I also say: I could go on with this but you get the point (I hope).

• "You" are the sponsor, and your context and objectives and measurements are different from "I". 
• I am the PMO; I respond to my measurements, incentives, and context.

We all notice: there is a gap. Sort of a Mars v. Venus thing. And, who is to manage the gap, a.k.a. the risk, between us? Well, that's why they pay PMO the big bucks! To manage all the risks, whether under their control and influence or not.

Project balance sheet
My icon for this is the "project balance sheet"

• "You" are on the left
• "I" am on the right
• And, I have the risk (gap) on my side

"You" have a top-down more-or-less "fact free" vision of things. "I" do things stick by stick, bottoms up, dealing with the facts and estimates. "You" and "I" never actually agree. But we get the gap close enough to move ahead. And, that's the way it is on Mars and Venus

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

NIST standards and peanut butter

---

I'm a fan of peanut butter. I have a jar in my hurricane supplies here in Florida.

Nonetheless, I was surprised open a recent NIST blog (*) to find out about "standard peanut butter".

Who knew? I guess there are standards for everything. (I wonder if this one is a good use of tax dollars, however)

From the blog, I learned:

" ..... packaged foods come with a list of nutritional values mandated by the Nutrition Labeling and Education Act of 1990, which is enforced by the Food and Drug Administration.

You may be less aware of where those numbers come from. Well, manufacturers don’t just make them up. They have to do tests. NIST develops food and beverage-related standard reference materials (SRMs) to help them know that those tests are giving them the right answers.

NIST chemist Carolyn Burdette with SRM 2387, Peanut Butter. Credit: B. Place/NIST

When a company buys an SRM from NIST, they are really buying all of the measurements and scientific expertise that went into determining its chemical or physical properties, as well as NIST’s level of certainty regarding those measurements.

(*) National Institute of Science and Technology

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog