MOP and MOE for the USA

Measurements are so crucial. But in politics today, measurements are rarely used for their intended purpose. Here I am going to try and select a set of measures, maybe 20? and track them to EOY 2026 and EOY 2028, in hopes of actually understanding relatively objectively the performance and effectiveness of the current USA Presidential administration as of early 2025.

A beginning note follows from my buddy Mike – see below for more on actual MOPs/MOEs we choose/chose. There will be lots of edits to this post if all goes well.

x continuing … (to be determined/edited)

Retrospectives in Battle

I have been lax in continuing my blog in retirement – sorry! We’ll see if I do better in the future. It is retirement, after all.

The following excerpt (italics) is from Air Combat at 20 Feet … Selected missions from a strafer pilot’s diary … by Garrett Middlebrook (“Middie”). This amazing book, borrowed from my friend Mark Dickerson, details missions from Middie’s diary of air and ground combat during World War II. He was the pilot and commander of a North American B-25 Mitchell. Shortly after arriving in the South Pacific his medium bomber aircraft was modified by adding strafing gun packs. This excerpt is near the beginning of the book. So often we learn too little from these gentlemen of our greatest generation, simply because it is too difficult for them to speak much about their experiences. No one blames them for this, but this man, Garrett Middlebrook, was up to the task of transcribing portions of his missions diary into an excellent book, and for that we should all be grateful.

That afternoon I met in private with my crew. From the very first mission we did something the other crews, except for Bill Gay, thought unnecessary. We critiqued each mission with a clear understanding that each crew member had the right to make any suggestion or criticism he desired. If I found that some suggestion was not practical, I never ignored the crewman. Instead, I explained to him detail why his idea was not practical or effective. 

On that particular day, however, I accepted all the blame and responsibility for having centered my attention on Parker’s plane [after the airplane was hit by the enemy and was going down], and for having allowed myself to become emotionally distraught with sympathy. Three other crew members confessed to sympathetic indulgence also.

I promised I would never again lose my trend of concentration [on the mission] by being sympathetic to a doomed crew, no matter who they were. I then advised my fellow crewmen that I expected them to refrain from sympathy and to maintain vigilance at all times. I suggested that we would have plenty of time for sympathy and sadness once we were back at base.

I kept my promise. I saw several planes go down after that date. When a plane fell from the formation, I always pressed the intercom button and reminded the crew to look up and not down. I asked them to fight for themselves and for each other so that the Japs would not bring us down. I received magnificent response on each occasion. They did not need morale lectures thereafter because we shared a common transition that day. We all became veterans. Although we endured and suffered through many [Japanese] Zero attacks thereafter, none ever surprised us.

I have two quick remarks on this sobering text. First, retrospectives are useful even in, perhaps especially in, the most dire of circumstances. Second, to accomplish the mission, sometimes one’s sole focus must remain on that mission. These lessons were learned the hard way, in battle. May those who fell rest in peace. 

Modern App Frustrations

Remember the good old days? Software came with a user manual. For complicated software, at least, the manual was indispensable. Complications were dealt with in a way reflecting a focus on procedure. In order to do mail merge, first do this, then this, then this … and so on, until you’re done.

example user manual
an ancient Rational Rose manual

Well, today’s apps are not this way. If there’s a manual at all, it’s online. More often, it’s a few youtube (this and other words herein are most likely trademarked so please assume that where appropriate) videos. However, there is something more fundamental going on. Let’s take your average iOS app. The same is true for Android apps. Such an app, at least if it is popular, is frequently updated. Many of my favorite apps are updated two or three times weekly. Some apps appear to be on an update schedule; others are updated on demand – “we fixed some defects”. Here’s a partial image of my iPhone screen from this morning; after a single day the App Store app has 16 updates.

iPhone screen
Sample screen from my iPhone

More importantly, there is no longer a focus on procedure. No written user manual would be effective, because it will be obsolete in two or three updates. They keep changing stuff! They think they’re making their app better for you. Sometimes they are. Inevitably, they change the way things work. In many apps, the only method you can use to get something done is as follows:

  1. I’ve done this before, now how do I do it?
  2. Review the screen thoughtfully, and click on something that looks like it might lead to my desired action – this may involve several attempts; a common but not-always-available heuristic is “oh, I remember this icon, let’s try that”
  3. Repeat step 2 until you’re on a screen containing your desired action, remembering that the icon displayed that means your desired action may not be the same as last time either

This can be incredibly frustrating. Every human enjoys procedure; it allows actions, especially common actions, to be formulated into a habit, so a lower level of thoughtfulness is required to undertake actions. The authors of some of my apps know this and minimize change per unit time where they can. The authors of most of my apps don’t really try, as near as I can tell; they think, “oh, this would be better, let’s do that”.

Finally, the older you are, the more difficult this transition is. Don’t ask me how I know this.

Remote Story Point Sizing

All you need is a chat window. No really, it’s true. (Though sadly, the reason I’m posting this is because too many companies, even large ones, are astoundingly reluctant to invest in the successful collaboration of their teams.)

Here is a script for sizing a small number of items one at a time using a voice conference call and a chat window; this seems like a small enough technology requirement to assure that almost everyone doing a remote team exercise will have the necessary technology. I’ve been honing the wording on this, as the slightest mistake in wording can lead to someone prematurely showing their size to others, which results in bias.

  • Your facilitator says, “Is anyone NOT clear on the item we are about to size?
  • If everyone is clear, then the facilitator says, “Ok, without typing the enter key yet, please type your size estimate into the chat window, sending to all; again, do NOT yet type the Enter key.”
  • The facilitator can type into the chat window, “Looking at item <number or description>” – this is an informative interstitial that separates this sizing evolution from a previous one.
  • The facilitator says, “Does anyone have yet to decide on a size?
  • If not, the facilitator says, “Three two one Vote“, and at that point everyone types their Enter key at the same time, on the spoken word “Vote”.
  • Of course, if everyone is agreed, then your item is sized.
  • Otherwise, one more round of voting can occur as above, after allowing for discussion, remember to get the high size vote and the low size vote in on the discussion to clarify their reasoning to your team. I recommend no more than two voting rounds total to save time.

One can do a Fist of 5 (Fist to 5) in this way also.

  • Facilitator: “I’d like to get a Fist of 5 to ascertain our confidence in meeting the sprint goal and sprint content to which we are about to commit.
  • Facilitator: “Without typing your Enter key yet, please type your number of fingers into the chat; again, do NOT yet type the Enter key.” Here also, you can describe what each number 0 (or 1) through 5 means as you are accustomed to using this consensus method.
  • Facilitator: “Does anyone have yet to type in a number of fingers?
  • Facilitator: “Three two one Vote” – as above.

I hope that helps! There are many other ways, but as most readers will already be aware, obtaining an unbiased response from each participant is important.

Theory. If you want to read more, try …

The Rudiments of Retrospective

I want you and your team to have good retrospectives. Retros are the most important mechanism for continuous improvement. There are so many articles out there with good advice. But I’d like my own anyway and discuss a few concepts.

Method variance (part of facilitation)

As I write this in late March 2020, most of us are WFH – working from home, due to the COVID-19 “Coronavirus”. Eliminating the ability to collaborate face-to-face makes varying the conduct method of your retrospective even more important. This is because the variance subtly motivates different perspectives, and that is an important way we discover new things to try (experiment) to improve. For example, suppose you want to hear from every team member. You can call on everyone in turn as the Scrum Master. You can ask each to choose their successor, you can intentionally randomize. You can ask “who would like to go next?” Each has advantages. Choose a different method for doing business as often as you can. Here is one ‘net resource discussing this idea; here’s another.

Framework variance

Most retrospectives have a framework for engaging in discussion resulting in specific elements of continuous improvement. Vary this too; no matter how inventive it is it gets old with overuse. Start/ Stop/ Continue is great, but there are so many others, some with interesting names like Sailboat, and again each results in different perspectives. Here is a list of 10 different frameworks including Lean Coffee.

Agenda

The agenda for a retrospective is more than just executing the framework. It’s also a look back and of course a look forward. Here is a sample agenda with a beginning, the “meat”, and outcomes:

  • Introduction (try the Retrospective Prime Directive)
  • Celebrations
  • What were the three (no more than 3) behaviors we decided to change last time? How did that go?
  • What were the three (again, no more than 3) retrospective backlog items, actions, we decided to work on last time? How did they go?
  • Framework choice (see above)
  • Framework-based, facilitated retrospective free discussion
  • What are the < 3 behaviors we will change for next time?
  • What are the < backlog items of continuous improvement we will work on and complete for next time?
  • Other remarks / Conclusion

Inputs

  • An invitation to meet, with agenda
  • Recent behavior changes – let’s call them decisions – we’ve been experimenting with (an example: we decided to do three backlog refinement sessions last sprint instead of two, how did this go?)
  • Recent backlog items – actions – associated with retrospectives (an example: we added a Jira issue to build a Slack bot to do (whatever) is this done and how is it working out?)
  • Framework choice (or, this might be revealed during the retro session itself)

Guidelines

  • Ensure that your retrospectives occur sufficiently often. Less than monthly is almost certainly unacceptable.
  • Ensure that the feeling of the session is not that of a report or reports. It is a collaborative discovery session.
  • Allow for anonymous input. If you were all in a room together, the next sticky note you place on the wall in conjunction with your framework-based discussion is at least somewhat anonymous. When we discuss it, the person who wrote it may or may not speak up, and if they do they may or may not own up to having written it. Try to encourage this kind of anonymity, as it frees up discussion and makes more innovation possible.
  • Take inputs and group them to improve effectiveness. It’s ok for multiple people to say the same thing. Group them after collecting them, to facilitate discussion. The face-to-face method is to grab stickies and group them together. Do what you can if you’re remote to make this happen.
  • Take your team’s inputs and prioritize them, at least most of the time – perhaps in the interest of varying method you don’t always do so, but most of the time you should. The Lean Coffee method works fine, most votes is highest priority. Discuss the topics in priority order.
  • Have fun! Celebrate!

Outputs

  • Those behavioral things we’re going to change and experiment with, that is our decisions, and
  • those actions we’re going to work on, and which therefore will appear in our backlog, both of these first two bullets in the name of continuous improvement
  • the date/time of the next retrospective
  • Don’t forget to celebrate! You need to work that in somewhere.

Project Management Lessons from Star Wars

“I learned everything I know about Project Management from Star Wars.” No, definitely not my idea, I just enjoy it. And actually the first person I heard utter these words is my old friend Bob Wise. Truer words, though, have never been spoken. Some brief evidence for your reading pleasure …

  1. First lesson: if possible, it is best to operate from a position of strength: (Ep. V)
    Darth Vader: “I am altering the deal. Pray I don’t alter it any further.” 

  2. The Good Cop, Bad Cop paradigm can be a useful negotiating tactic: (Ep. VI)
    Moff Jerjerrod: “The Emperor’s coming here?”
    Darth Vader: “That is correct, Commander. And, he is most displeased with your apparent lack of progress.”
    Moff Jerjerrod: “We shall double our efforts.”
    Darth Vader: “I hope so, Commander, for your sake. The Emperor is not as forgiving as I am.” 

  3. Schedule … of course … as always … is paramount: (Ep. VI)
    Moff Jerjerrod: “Lord Vader, this is an unexpected pleasure. We are honored by your presence…”
    Darth Vader: “You may dispense with the pleasantries, Commander. I’m here to put you back on schedule.”

  4. Always work to enable, facilitate and motivate your team: (Ep. VI)
    Moff Jerjerrod: “I assure you, Lord Vader. My men are working as fast as they can.”
    Darth Vader: “Perhaps I can find new ways to motivate them.” 

  5. Somewhat less tongue-in-cheek, we have the following genuinely useful thought from Annakin’s mother to her son: (Ep. I)
    Shmi Skywalker: But you can’t stop the change, any more than you can stop the suns from setting.”

I recently discovered that others have taken it to a much higher level (no surprise!): 

  • Brandon Koeller: Top 10 reasons Darth Vader was an amazing project manager[1]
  • Tim W: Five ways Project Managers could have saved the Empire[2]

  – – – – –

Enjoy …


[1] https://www.geekwire.com/2011/top-10-reasons-darth-vader-amazing-project-manager/ .

[2] https://www.linkedin.com/pulse/star-wars-five-ways-project-manager-could-have-saved-empire-woolery/

Reading, Commenting, Logging in – on WordPress (my blog host)

Some of you have noted that it’s difficult to comment; let me address that here please.

  • Upon arrival at densmore.lindanbaum.us you are presented with a welcome image that includes a little arrow at bottom right. You can scroll down to read content (multiple blog posts, reverse chronological order), or you can also use that arrow to scroll down – your choice.
  • If you wish to comment on a post, click the title of that post – now you’ll be on a page that consists only of that post. At the bottom of the post, there should be a place to add your commentary.
  • If you are not logged into WordPress it tells you there that you must be, in order to comment. Click on that message itself to get to the login screen so that you can login. If you don’t have a WordPress account it forces you to have one, at least for those of you who still wish to comment.
  • No one has told me of any harm associated with having a WordPress login, other than the requirement to remember yet another stupid password #yasp. Please let me know if you become aware of a counterexample.
  • Perhaps some of these website designers get too cute and cryptic, but that’s what I’ve found that works. Thanks for listening and persevering.  –Jim & Linda, 24-Jan-2018

Rampant Complexity in Software and Systems

I’ve been espousing for awhile now about #rampantComplexity, posting the occasional article where software and systems are needlessly hard to use or chaotically interacting. Recently I have experienced several examples right out of my home. Generally I think these issues point to complexity, to way too little automated testing and automated regression testing, and finally to too few developers and product managers who understand how to elicit good requirements and usage scenarios (today called user stories, in the past often called use cases).

  1. Our new dishwasher. It’s a simple thing: like every other dishwasher I’ve ever had, I’d like to be able to warm dishes in it. I’ve even had some with a “warm dishes” setting. However, my current model just has a few cycle options. All imply getting the dishes wet first. There’s no dry-only or heat option. Why are they taking functionality away from us?! #DontTheyThinkAboutUseCases?
  2. Our microwave and oven combination is hilarious, there are so many little things wrong with its user interface. First, there is a button lock. If you push these three or four buttons in this order, the interface locks, and an unlock button appears on the face. It turns out that the easiest way to lock the interface is to wash the face of the unit with a cleaning cloth. My wife has done this several times unintentionally; she then comes to me wondering why the appliance no longer functions. My explanation makes sense but she has forgotten about it weeks later when the problem reoccurs. #DontTheyThinkAboutUseCases?
  3. Moving to the next microwave/oven interface issue, if you open the microwave door to check on the progress of the object you’re “nuking”, you can then close the door and elect to turn it back on and continue heating the item. That continue button works about 90% of the time. Sometimes though it just ignores you, and you are forced to completely start over. #DontTheyTestThisStuff?
  4. There is a delayed start option for the oven, but I am not patient enough to figure out how it works. There is a store program option as well, but it is not obvious what a program even is. The documentation is unfathomable. #RTFM
  5. If the recipe says set the oven temperature to 365 degrees, one cannot follow the directive. The interface is a cool-looking slider, and it’s limited to 25 degree increments. Oh wait. Two years after writing that, I’ve discovered there’s an additional interface that allows 5 degree increments.
  6. The refrigerator has an aural beep which repeats, informing you that the door has been left door open. An almost-closed door is open in the eyes of the software, but the speaker is inside the refrigerator so it’s muffled by the mostly-closed door. Linda has some hearing loss and cannot hear the tones at all unless right next to fridge.
  7. The same sound is emitted by the refrigerator if the temperature inside is too high. Typically this occurs because the door was left open for some period. Of course when we discover this we close the door. The sound continues until the temperature is restored to 38 degrees by the fridge. There is no way to defeat this annoying sound. Even though the door is closed, the sound continues ad nauseum.
  8. I have an antique in my garage, a 1995 Explorer. To be fair, our community’s knowledge of systems complexity was much less mature in those days, but it’s still in my garage, and I love this wild story. The car has an outside air temperature (OAT) sensor in it, and a display for that temperature in the car, overhead between the front seats. I found out at my Ford dealer the location of the OAT sensor: it’s in the engine compartment. Really? There’s more noise in there than signal!! As it transpires, in the instrument cluster there is an ECU (CPU for computer guys, ECU means electronic control unit), and it has an algorithm running which understands the current state of the system (how long the engine has been running, etc.) which compensates for the noise. Wow. Over many years I’ve found that the algorithm is right to within about 4 degrees most of the time.
  9. But wait, there’s more. In the next model year 1996, a different climate control system vendor was used, and it had an OAT display. The vendor wanted a feed from the OAT sensor. Whoever they asked was aware of the sensor and the algorithm, but instead of passing along, say, an API, to get at the algorithm’s output, they were handed a requirements document explaining the algorithm. The vendor functionally duplicated this algorithm in their climate control system. All was well until in the field, customers reported that the two OAT readouts were Not Always The Same!! Implement a complex algorithm two different ways, and you can often see this happen for yourself, and the hardware running the algorithm was different also. They apparently performed a recall over this. Sadly, most recalls cost an extraordinary amount of money.
  10. Though our 2011 Escape does not suffer from this problem nearly as bad as some of the newer cars out there … I tweeted (as this was originally written, in 2017, but I’m no longer on twitter) about new cars and an article about them written by the WSJ. “Touchy touch screens, buggy software, mystery sounds, all baffling to drivers, forcing some to enroll in two-hour seminars. And then the beeping started …” I’ve seen this with a variety of people in my life, but most especially my mother, who wouldn’t even dream of buying a laptop computer much less a new car. She hung onto her 1993 Thunderbird until she gave up driving last year. (The WSJ article is here I hope you can see it despite the paywall)
  11. Recently, when my wife Linda tried to visit to her work website, nothing happened, she’d get just a blank screen and spinning. She could visit any website we could think of … except her work website. We decided to investigate. Her work website worked fine on her iPhone and several other devices, but still not on her work PC. We cleared all the stupid caches, cookies and crackers – no help. We tried two other browsers, one freshly downloaded – no help. Rebooted the laptop – no help. Shut it down and waited 5 minutes, rebooted the laptop – no help. Linda called the tech support folks, they read from their scripts – no help.  Then I power-cycled the cable internet modem in the house to reboot it. That worked. *sigh*

What would YOU do to try and keep these issues from arising in your next product effort?