The business made me do it!

---

Is this the ultimate angst of micromanagement?

First, you push on your territories [work packages] where you have no business to be, and where you had promised not to go; secondly, your intrusion provokes resentment, and resentment means resistance.

Thirdly, you instantly cry out that the people [teams] are rebellious ...

Fourthly, you send out a force [PMO helpers] to stamp out rebellion; and fifthly, having ... spread confusion... you declare .... that [business] reasons forced you to stay....

Viscount John Morley

State Secretary for India

1905 - 1910

Of course, Morley said it slightly differently; he actually didn't mention work packages and PMOs (Shocking!) You can find Morley's more complete quote on the first page of David Ignatius' spellbinder "Bloodmoney"

Jeff Foxworthy probably has never said "you know you're a micromanager when...", but if he had, he might have said: you know you're a micromanager when you say:

a. I'm not a micromanager; I let my people make the decisions
b. I'm not micormanaging; I'm mentoring the team
c. Some people simply can't accept input
d. I can't let this happen on my watch, so I have to be involved.

The Viscount couldn't have said it any better than Foxworthy!


Bookmark this on Delicious

Agile and the DoD (again)

---

David F. Rico has a presentation about Agile in the DoD. He presents a compelling case for agile in large scale systems and in enterprises steeped in traditional methods, and those highly regulated for quality and compliance to standards.

There is both a video of his presentation, and a slide set. You can get all the details for accessing the video at Herding Cats. Once you're into the video, you can click on the right-side panel for another window to open with just the slide set.

---

If you're interested in other perspectives, search for 'agile' in the online journal for DoD software engineering "Crosstalk"; there are dozens of good articles there on DoD projects and process.

---

Another summary of things going on is given to us by Jeff Sutherland on his "DoD goes Agile" posting. He (Jeff) quotes from the 2010 Defense budget authorization bill:

The key language is this:

(2) be designed to include—

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; and

(D) a modular, open-systems approach.

Basically, for the DoD at least, Agile became the law. Here's the report the DoD returned to congress

Or, for my perspective, you can read here or below:

Agile and the DoD

View more documents from John Goodpasture

Bookmark this on Delicious

Three strategies for strategic actions

---

In a recent issue of Strategies+Business, authors Tim Laseter and Saras Sarasvathy tell us about three different approaches to strategic actions. After reading through it, I understand their three points, but I think their first one is academic filler... but you judge for yourself:

Approach 1: Planning and Positioning. Characterized by knowledge of the probabilities and impacts of risk events. Decisions to maximize strategic value are made on the basis of expected value. Typical tool is the classic decision tree

Approach 2: Organizational Learning: Probabilities (and therefore probability distributions) are unknown, so risks are now "uncertainties". Events, conditions, and perhaps impacts can be estimated, but not their frequency. This has been termed Knightsian Uncertainty, named for its conceptualizer, Frank Knight who wrote it all down in in book: "Risk, Uncertainty, and Profit".

One really important idea here is that the first step in assessing uncertainty is to estimate whether the downside is affordable. If not, then that's to be taken care of first. Then, choices can be made about the strategic upside of opportunity. Expected value usually doesn't enter the picture since there's no knowledge of probability.

Approach 2 has buried in it our natural avoidance of ambiguity. When the stakes are small, we may choose strategies that are vague but probably doable. But as stakes change, so do attitudes.. bigger stakes, more conservative, eschewing ambiguity for more clarity; in effect, a violation of utility. An understanding of this is generally credited to Daniel Ellsberg, and called the Ellsberg Paradox.

Approach 3: Constructive Transformation. In this strategic formulation, you more or less take what live gives you and then make something out of it. In other words, you don't lead with vision; rather, you lead with process (and tools, and talented people). So, this is something like what Lou Gerstner said when he took over IBM. In effect, when asked about his vision for IBM, he said he didn't need one. What he needed to do was to get the machinery of IBM working again. This, of course, he did, and he did it quite well.

Constructive Transformation is something akin to abductive reasoning: that is, you hypothesize what might be possible that could link many disparate events, objects, or conditions.

So, what do you think? For my money, approach 2 or 3 are close to the way it really works. Approach 1 is theoretically correct, but generally impractical because the information simply isn't available to drive the decision tree.

Bookmark this on Delicious

Wise delinquency

---

Could this be true? (If so, it could put a lot of consultants out of business)

... when decision makers use informal deliberative techniques rather than textbook formal decision methods, they are usually doing so quite appropriately, since deliberation better fits their decision challenges than those formal methods.

This is the editor's lead-in to "The Wise Delinquency of Decision Makers", an article by Tim Van Gelder in Quadrant, March 2010 No 464 (Volume LIV, Number 3), p.40-43

I was put onto this by an interesting post on IBIS, a structured decision and argument tool, by EightToLate

So, what does brother van Gelder tell us? After interviewing a number of military officers (and others), all trained in depth in decision methodology, he concluded that few ever used their training explicitly for decision making. (We have to be careful here since we know from proven research that intuition is a learned response from real experience; thus, we can't dismiss their training out of hand. See: Gladwell, or Kahneman, among others)

He gives us this anecdote:

Some years ago I (Percy Diaconis) was trying to decide whether or not to move to Harvard from Stanford. I had bored my friends silly with endless discussion. Finally, one of them said, "You're one of our leading decision theorists. Maybe you should make a list of the costs and benefits and try to roughly calculate your expected utility." Without thinking, I blurted
out, "Come on, Sandy, this is serious."

Oh well!

van Gelder gives four reasons for such delinquency:

• "First, there are the intrinsic biases and limitations built into each of our minds by virtue of the fact that our thinking equipment is the result of a long, haphazard and incomplete evolutionary process.
• Second, there are the ill effects of the passions—temper, envy, pride, fear. Emotions are an unavoidable and often helpful aspect of human decision-making, but they can also be the enemy of wisdom.
• Third, there are problems which arise due to the fact that important deliberative decisions are often made not by individuals but by small groups such as boards or committees.
• Finally, compounding the above is the untutored manner in which people engage in deliberation. The regrettable fact is that few people have ever had any training in the art of deliberative decision-making."

Good grief! It's a wonder that anything gets decided on its merits!

---

Bookmark this on Delicious

More about adoption

---

There's no time like the present: Let's start now to figure out how project value is going to morph into business value. Hopefully, your question is not "what is business value?". That question should have been answered in the business case. So, I'll presume it was, and move on.

Adoption may be slow. Do you recall Kurt Lewin's model for change ? (it was postulated in the 1940's. And, if your recognize the name, he's the guy also credited with Force Field Analysis). The model is actually pretty simple (three steps), but it gets at the "slow adoption" thing:

• Unfreeze, meaning overcome inertia, get everyone on the same page, and create the urgency or passion for the change
• Make the change, meaning roll it out and then work on the kinks
• Re-freeze, meaning institutionalize the change so that it sticks

Well, of course, if there's one rollout, and one adopter community with one set of attitudes, then Lewin's process fits. Modern business is more complex (it probably was in the '40s also, but models need to be simple to get traction) so this three stepper may not fit today's business dynamic exactly as posed, but it's got the seeds of the right things to do.

Let's start with unfreezing. Assume there's an effective "change is coming" communication campaign, and assume there are some incentives for managers to get on board. What about those that are volunteers, like customer and users?

Let's start with Early Adopters

There are, of course, those who will eagerly grab new capabilities, especially technology capabilities rich in software features and functions, and especially those that are user-configurable. So, let's make it easy for them.

• We need easy access to the change (product, process, or whatever) 
• We need good personal support in the beginning that can morph to more institutional support later
• We need the supply chain on board;
• We may need other third party partners on board.
• We've got to decide how private and proprietary this change is going to be, or how much of the intellectual property is going to be made available to others.
• We need a process for absorbing what the EA's tell us so that for those adopters that come later they will be more satisfied.

But early adopters are only one of five personalities in the body of knowledge known as diffusion of innovations. Because of the natural reluctance to change, embracing new capabilities may not be automatic. To encourage adoption, competing or legacy capabilities should be withdrawn as soon as practical.

The five are:

1. Innovators: Those who are anxious to work with the product in a preproduction or beta status and take risks with immature product; usually very personable and networked individuals, well connected with technology, and able to handle a high degree of uncertainty;

2. Early adopters: Those with opinion leadership eager to put product through its paces and be first on the block to have the advantage of a new capability;

3. Early majority: Those willing to adopt after visible proof that the bugs have been worked out and operational effectiveness has been proven;

4. Later majority: The reluctant but willing, not too comfortable giving up what they know best; and

5. Laggards: Those that might never adopt and so drop out of the pool of users.

Innovators often make their own decisions to engage using new ideas; they are often in at the beginning and may be drivers behind the original vision. Early adopters may wait for official sanction before taking up a new product; later adopters may be forced by decision makers to get involved. Regardless, Everett Rogers, one of the early academics in the theory of diffusing innovation, posits that everyone passes through a five-stage decision-making process, albeit on difference timelines.

Roger’s paradigm is:

 

1. Seek knowledge: Seek basic information to become familiar and acquainted with a new idea, product, or service;

2. Accept persuasion: Evaluate benefits in context of personal use and application;

3. Decide: Decide to adopt or reject;

 

4. Implement: Begin to apply the product or service to the everyday routine; and

5. Confirm: Accept the product as a fully qualified alternative to the prior capability.

 

When you think about it, Roger's paradigm simply added a bit to Lewin's three stepper, but they largely are in agreement.

 

And, one other thing from my experience:

• Remove the legacy (you can't hang onto what you don't actually have)
• Deploy 'ambassadors' to every functional unit who are expert. Their job is to nip any whining in the bud 

 

Bookmark this on Delicious

Picking a pilot project

---

In every class I teach, pilot projects come up for discussion, to which I respond: pilots are good. It's a learning experience, and it's a way to work out the message when you take it mainstream.

 

What makes a good pilot? Mike Cohn has a posting on this, and as an extra added feature, he has drawn a swell zen diagram to put it all at a moment's glance.

 

Mike's advice:

• Pick a project that is mid-size for your enterprise re duration and budget
• Be sure to pick a project that has some stakeholder support
• Pick a project that is obviously important--but not too important

 

So, don't do these things

• Don't wade into a "wicked" social policy problem and offer a quick fix on a small piece of the puzzle
• Don't pick a project that is too fuzzy on 'done', competing too much with on-going operations, and thereby muddying the metrics
• Don't pick a project that is "bet the business" for either a stakeholder or the enterprise. If you're going to gore someone's ox, pick a small ox.

In other words:

• Pick something you can actually get done
• Pick something that you can actually measure the difference with some benchmarks of other methods
• Pick something that functional managers are like to cooperate with (not too many functional nemisis while you work out the method kinks)
• Pick something that will exercise the methodology you want to adopt. No point in piloting only one or two points of a new method

Got it?!

Bookmark this on Delicious

No more self-organizing teams

---

I like headlines that have a simple message

This one--No more self-organizing teams--caught my eye for three reasons:

• I agree with the sentiment
• It was written by Jim Highsmith, who rights some good stuff
• I have an interest in leadership per se

Now, to be fair, Mike Cohn has an excellent counter-point blog, except he more or less supports the thesis we present here when he (Mike) quotes Philip Anderson who writes in "Biology of Business"

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is. (1999, 120)

But, back to the headline: What did Mr. Highsmith tell us? (Of course, he said more than these bullets, but these are the highlights)

• There is just too much experience and management literature that shows that good leaders make a big difference
• There is a contingent within the agile community that is fundamentally anarchist at heart and it has latched onto the term self-organizing because it sounds better than anarchy. However, putting a duck suit on a chicken doesn’t make a chicken a duck.
• Delegating decisions in an organization isn’t a simple task; it requires tremendous thought and some experimentation
• Leading is hard. If it was easy, every company would be “great,” to use Jim Collins’ term (Good to Great ).

What did he not tell us?

• Dominance is a human trait not easily set aside; thus the natural leaders will come to the fore and the natural followers will fall-in thankfully. There's no need and no practical way to rotate the leadership once dominance is established
• Like it or not, positional authority counts for something in all but the smallest enterprises. Thus, senior managers are senior for a reason. It's hard to establish credibility with the stakeholdes that hold the key to resources if the team is being led from the bottom of the pecking order.
• Self-organization may deny biases and bully the nemisis off the team. Group think, anyone?
• Delegation is a tricky matter: do only those things that only you can do

And the answer is: according to Highsmith, something called "light touch", but in reality it means leading and managing from a position of trusting the team, but mentoring the "self-organization" towards a better day.

Bookmark this on Delicious