Tag Archives: Executive

Ethical Action is not Moral Certainty

Posted on by

“With malice towards none; with charity for all; with firmness in the right as God gives us to see the right, let us strive on…” — Lincoln’s Second Inaugural

Roger Boisjoly was a Thiokol engineer who found “large arcs of blackened grease” on the solid boosters recovered from successful shuttle launches. He identified a correlation between cold temperatures and leakage of hot gases from the O-Ring seals in the solid boosters.

In January 1986, based on Boisjoly’s analysis and forecasts of cooler temperatures than ever experienced during a shuttle launch, Thiokol recommended the shuttle Challenger not launch.

NASA could not proceed over the contractor’s objections. “Appalled” by Thiokol’s recommendation, NASA held a private caucus with Thiokol management. A senior Thiokol executive was asked to, “take off his engineer hat and put on his management hat.” (Rogers Commission, 1986)

As a result, while still expressing concern, Thiokol withdrew their objection for lack of definitive proof. The age old argument for ignoring risk. By definition, no risk is certain.

Space Shuttle

Challenger exploded during launch killing all seven aboard.

In the aftermath, Boisjoly testified before the shuttle commission which is why we know all this.

As a result of coming forward, Boisjoly experienced such a hostile workplace he was granted sick leave and then extended disability.

In 1988, Boisjoly was awarded the AAAS Scientific Freedom and Responsibility Award. He is a role model of ethical action.

The most important thing to learn from his example is that ethical behavior is not about being right or infallible.

Despite his expertise, in[sight] and integrity lives were lost. At points he respected the chain of management even though he clearly disagreed with their decisions.

However, when it became clear he had, against his best efforts, contributed to tragedy, he stepped forward despite the consequences.

Human judgment is fallible but we must act to create the most benefit and least harm in accordance with the principle that others have as much right to joy, fulfillment and dignity as we do ourselves.

If harm results from even our best efforts we must take responsibility.

No one is perfect and there are always mitigating circumstances but there are also no excuses.

[NOTE: The Boisjoly Case Study is borrowed from Engineering Ethics: An Industrial perspective by G. Baura.]

Just do it!

Posted on by

Just Do It by kjudy

I laughed out loud when I saw Ken Schwaber titled a passage of his book, The Enterprise and Scrum, “Just Do It”.

Ken describes how a customer can sacrifice quality and sustainable pace in the short term but pay it back at a premium, “$4 to remediate every $1 drop in quality.”

Clearly there are pressing bugs, misses and serendipitous opportunities. There are times to inject work into a sprint backlog. There are even times to “stop the line” and reset a sprint.

But when you manage a self-directed team, “just do it” — and I’ve heard that very phrase — is bullshit.

Just characterizes another person’s work as easy. It is the people performing work that need to estimate it. They are on the hook to execute and are incented to think critically in detail about what they are taking on. The worker grasps the actual effort better than the executive.

Do characterizes the work as physical action. Software development is problem solving and abstract modeling, i.e. knowledge work. “I’m typing as fast as I can?!” Even industrial lean practice relies on workers engaging beyond the boundaries of the immediate task to improve the product and the process of manufacture.

It characterizes the work as a single, clearly defined task. Again, the person doing the work determines whether they clearly understand assignment. Otherwise, you’re not admitting to any ambiguity of language, hidden complexity, or potential misunderstandings.

Just do it is a one way directive that splits responsibility from authority, i.e. YOU just do it. It signals a leader is not willing to do their part to remove obstacles for their team.

Just do it hides inefficiency under a veneer of necessity. Is it a surprise that “just do it” finds companionship with “just the way things are done” and “just the nature of the business”?

All this to say “just do it” in knowledge work is bullshit. The value lies not in the truth or falsity of the statement but the effect it has on the hearer. It dismisses workers’ concerns and excuses management from accountability.

Moving from bulls to birds, if self-directed teams are the goose that lays golden eggs, “just do it” is a pellet blast in the ole’ egg layer.

The Road Not Taken

Posted on by

Mountain Path Ript - Photo by Kathie Horejsi

I began advocating agile principles at my company four years ago. Over time, my co-workers and I have grown into a Scrum/XP team. We have a track record of successful projects and a handful of supportive sponsors. Senior executives value our developers. My CTO understands the team dynamic itself is the prize asset.

Having reached a milestone on one of our larger projects and seeing ambitious work ahead, I wanted to write about how I stood at a crossroads: contribute to the team or attempt to nurture agile values elsewhere in the organization.

It’s a pleasant, contrasting choice. But it assumes a lone agile team can thrive after becoming visible to the larger organization. There are two pressing reasons why I doubt this is true:

  • An agile team attacks impediments from within or without. Either the team makes progress against these obstacles or it declines.
  • Human nature abhors exceptions however exceptional. If the organization doesn’t become a little more like us, it will surely, inevitably re-make us to be more like it.

Mountain Path Ript - Photo by Kathie Horejsi

So, no crossroads. One path lies before me and it looks surprisingly familiar.

As I did four years ago, I must advocate agile from within and peer to peer. This time around, I have success at my back but face longer odds.

Scrum the project. Scrum organizational change.

I can only make progress one step at a time. I must demystify what we do by allowing more chickens into my team’s reviews. I must find and coach others predisposed to agile values. I must find at least one executive willing to scrum a thorny project with their staff. If I get the chance, I must seek out expert coaching for those above and across me in the organization.

As four years ago, success relies more on others than on myself. But I believe, as before, that not trying is worse than failing in the attempt.

Context Switching

Posted on by

My team is currently working on two very different programs by pulling work off both backlogs into a single sprint. We did this for pragmatic reasons having to do with our size and the wishes of both the product owners and the team. This was working well when the two programs were clearly defined projects. However, we’re going through a rough patch with one program driving maintenance work and the other rallying towards release. We’re paying a price for context switching with lower point commitments overall per sprint.

Inspect and adapt.

The Washington Post published an article by Lori Aratani, Teens Can Multitask, But What Are Costs?

When subjects were focused on sorting, the hippocampus — the part of the brain responsible for storing and recalling information — was engaged. But when they were multitasking, that part of the brain was quiet and the part of the brain used to master repetitive skills — the striatum — was active.

The Journal of Experimental Psychology published a paper by Joshua S. Rubinstein, David E. Meyer, and Jeffrey E. Evans on Executive Control of Cognitive Processes in Task Switching. As an APA release summarizes:

…subjects lost time when they had to switch from one task to another, and time costs increased with the complexity of the tasks, so it took significantly longer to switch between more complex tasks. Time costs also were greater when subjects switched to tasks that were relatively unfamiliar.

Neither the article or paper distinguish results by gender. The First Sex says that according to gender specific studies women are better multi-taskers than men.

I bring up the gender differences because I work at a women-owned company. One of the benefits is seeing the world from my CEO’s point of view. Sometimes not identifying differences between men and women denies women opportunities, or worse, perpetuates harmful stereotypes. As a society, we are late to acknowledge that women present with heart disease differently than men. This has perpetuated a myth that heart disease is a male illness.

“(A)ccording to the American Heart Association (AHA), more women than men die from heart disease in the U.S., and 1 in 3 women is living with it today” – TIME Magazine

If women are truly better multitaskers, maybe they have some inherent advantages in certain kinds of jobs (like mine 🙂 ).

Both the men and women developers in my team have acknowledged that the context switching penalty has gotten worse recently. So whatever the difference in this case, some kind of scrum master response is required.