Remembering on Memorial Day

---

The last Monday in May is Memorial Day in the USA. A day we remember those who served, those who left it on the field, those who did not come back.

US cemetary at Omaha Beach, Normandy, France
(Photo by author)

---

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

Lessons on architecture

---

I love architecture, though I'm not an architect, and never studied architecture. Of course, I love system architecture, which is both different from building and construction per se, and identical -- because a building is a system, just as any other such integrated structure is a system.

Frank Gehry is one of Canada-America's more esteemed architects.  He does projects around the world.  The picture is of the museum in Bilbao, Spain.  Of course, Gehry always designs some pretty unusual stuff, having said things like this about his projects (take note: these ideas scale pretty well; there's nothing inherently 'small' or 'large' about any of them):

• Models: thorough with the envisioning and conceptualization, Gehry often building 100 models before he 'sees' it.  (Spiral method, anyone?)
• Customer commitment: makes a priority of customer buy-in, and in the end, the customer never regrets -- editorial: never say never; and the ultimate buy-in may be the embedded customer
• Functional success: Wow! it has to work.  Has everyone heard and internalized that one? It's pretty hard to general value, even intangible value like 'esteem', if the thing doesn't work, or the roof leaks, etc
• Practical to build: You have to be able to actually build it:  technologically feasible and feasibly economical (perhaps we should revisit the Sydney opera house--not a Gehry design -- for a lesson in 'can you build it' and if you can, can you afford to build it?), and
• Other people's money: It has to meet a budget! (Back to PM 101, and the consequences of "other people's money")

Actually, on these last two points, another flamboyant architect, Frank Lloyd Wright, never actually got it.  Many of his buildings didn't work (roofs and windows leaked, for one thing), and he rarely (some say never) met a budget.  And he didn't miss closely, he missed by a mile!

Some of these problems are like any 'new to the world' endeavor: stuff happens!  But some is just downright delusional or deliberately deceptive.  Some advice just never gets old: Buyer beware!

---

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 Brain and the Decision

---

Since at least the 1970s we've all been acutely aware of the vagaries of the influence of the brain processes in concert with environment and context on decision making. Fair enough

For those that are not so acutely aware, begin with the work of Daniel Kahneman and Amos Tversky -- their stuff is the classic treatment

Now comes more on the same line of thought -- no pun intended
No less an authority than Oppenheimer Funds posted an ad for financial decision making that had some good points for project managers

•  First, as a matter of review, rational thought and emotional thought are supported differently in the brain: the latter in the limbic region and the former in the frontal lobe. So, each of us are likely equipped differently for the two thought influences ... Mars and Venus, as it were
• Second, all decision making is a mix of the rational and the emotional. Some studies, reported elsewhere, have shown that under conditions of brain injury, a rational brain may get into an endless do-loop and not break out to a decision without a dose of emotion.
• Our personal biology, beyond even the brain, is an influencer: reactions to gut feelings, etc in the "body-brain" system
• Stress responses trigger hormones, and these in turn, through the body-brain thing, influence risk taking.

That is, risk appetite can vary with stress. It's not altogether fixed by context, experience, and track record. Risk appetite can be "in the moment"

---

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 value of an idea

---

"Managing project value" has been a theme I've written a lot about -- I've even written a whole book about it (Did you notice the book cover below?)

So, I was fascinated with a series on the Kahn Academy about the value of a start-up. Admittedly, venture start-up is a little off the bore-sight of a project, but not that far off. This because a central tool in my thinking is the "project balance sheet" between the business (value, resources, commitment) and the project (deliverables, schedule, resource consumption).

The main tool in the business value presentation by Sal Kahn is the business balance sheet, beginning with the value of an idea, and the value of critical or unique skills.  These assets are balanced by a valuation, first just a division of made-up equity, but later by a division of real money.

Somewhat like agile ideas, and other incremental methodologies, Kahn up-values the idea each time there is something concrete to show that is progress toward making the idea a business reality. Ultimately the market makes the valuation, but in getting there it's much like the accumulating value earned along the way by more and more deliverables.

Give the series a look and listen; there's much to be learned.

---

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

SCRUM is about people

---

Looking to hone your people skills and tie into SCRUM?

Here's a seminar -- free even you are not a member -- that is more or less on the theme: "SCRUM is about people".

---

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

Truth and myth

---

Glen Alleman recently quoted Kennedy:

For the great enemy of truth is very often not the lie ― deliberate, contrived, and dishonest ― but the myth ― persistent, persuasive, and unrealistic. Too often we hold fast to the clichés of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought. ― John F. Kennedy

And so we have lots of myths in our industry:

• Projects don't fail using Agile methods -- actually, some do
• Earned value projects have better success rates -- probably not. EV is not the problem, nor likely the solution
• Smartphones with encryption can't be opened -- well, that one got shot down
• No encrypted file is safe -- actually, some are, though somewhere there is a "plaintext" file

---

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

Technical debt -- A definition?

---

Technical debt: we've all written about it; I've described in my book, Project Management the Agile Way (see below), but I guess the industry has never settled on a formal definition.

I've always thought of it as a "punch list" that is a "debt" that must be retired in the future .... stuff that needs to get DONE or fixed so that we can say to the sponsor: hey, it's DONE and the QUALITY is built in.

I saw this definition recently. Frankly, it's a little too formal and I think it actually misses the point that debt may be as simple as a low level test not completed; a color not made right; a functionality with a bug that occurs very infrequently, etc.  Nonetheless, here it is for your consideration

In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term, but set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability [SIC].

If you click back to the original source, you pick up on this explanation which adds a bit of color commentary, to wit:

This metaphor is in essence an effective way of communicating design trade-offs and using software quality and business context data in a timely way to course correct.

While other software engineering disciplines such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering have produced results relevant to managing technical debt, none of them alone suffice to model, manage, and communicate the different facets of the design trade-off problem at hand.

Of course, I take a bit of issue with the last phrase "design trade-off problem at hand": technical debt is not exclusively -- or even -- about design trades per se; as before: it could be as simple as a low level test not completed. One wonders if the guys who wrote this stuff have actually ever done it.

---

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

Engineering brillance, but not a visionary

---

Here's a good TED talk as an interview with Linus Torvalds, the geek of geeks, and inventor of LINUX and Git

Linus Torvalds transformed technology twice — first with the Linux kernel, which helps power the Internet, and again with Git, the source code management system used by developers worldwide.  "I am not a visionary, I'm an engineer," Torvalds says. "I'm perfectly happy with all the people who are walking around and just staring at the clouds ... but I'm looking at the ground, and I want to fix the pothole that's right in front of me before I fall in."

• 
  

---

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

Sprint plan: common sense goes here

---

Now, let's here it for common sense! More and more I see this asset creeping into the advice we get about Agile, and even more so about how to handle the various things that show up in a sprint.

The latest: trying to "freeze" hard the sprint backlog may be impractical. It may be more slushy than a hard freeze. [Didn't we all know that all along?]

In an email blast of a blog posting, guru Mike Cohn tells us that sprint teams may be exposed to changes during a sprint. He calls them "interruptions", and so that is probably a better term, since all interruptions are not changes in scope, but they may bring about changes in the plan to apply resources to the sprint backlog.

However you look at it, Cohn uses this image to explain that "stuff happens":

Of course, every author who writes about Agile, including myself in both editions of my book (see below), writes about the need for white space, unallocated or unplanned time, or buffer periods, to include whole sprints as buffers (zero-scope sprints)

My own experience was with the Air Force on a back office project with a joint staff: On certain days, the military staff members would be on the parade ground or off on some exercise rather than being in the project space adhering to the schedule. Some planning for "corporate overhead" required, to be sure.

But, beyond the overhead, still it is that "change happens" and is brought to you by none other than your product owner or product manager. Though these folks are chartered to maintain discipline re scope changes, sometimes the change invades what is otherwise "iceland" (small i) ... the land of frozen sprint backlog. 

---

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

Fault and Root Cause Analysis

---

FARCA -- Fault and Root Cause Analysis -- is what you do when you've got observations and symptoms of outcomes, but no real supporting explanation of the underlying causes and failure modes.

Every PMO admonishes: Don't act on symptoms! Get to the 'facts'. Find out what's causing this

And thus: deductive analysis*. When you've got the answer; now you must discover the question.

Naturally, there is the "five why's" analysis to kick it off: ask why five times in a indentured set of questions. You may indeed get to the root cause.

But, if you really need to do analysis, then here's a methodology training aide in just 71 pages!

*[Of course, there's the corollary, Inductive analysis: You got the question -- what happens if ... -- but you don't have the answer. See: "For want of a nail ..." ]

---

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