To self-organize, or not?

---

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 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 nemesis 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.

---

Buy them at any online book retailer!

Behavior v Outcome

---

You have to give Jurgen Appelo high marks for imaginative illustrations that catch the eye and convey the thought. He says this is one of his best illustrations ever; he may be right. He calls it his "celebration grid". I imagine Jurgen will be telling us a lot more about this if it catches on.

But what he says about these grid points is the more important take away:

• “Celebrate failure” is nonsense, because you shouldn’t celebrate failure that comes from mistakes (the red part). What you should celebrate is learning, and repeating good practices (the green parts).
• Pay-for-performance tends to drive people away from experiments, toward the safe practices on the right, with little learning as a result. 
• Hierarchies are good at exploiting opportunities, and endlessly repeating the same practices; but they learn very little. 
• Networks are good at exploring new opportunities, and failing half of the time, but they’re not good at efficiently repeating practices.

File this under leadership for learning and motivation, change management, managing team dynamics, and carrot and stick.

---

Bookmark this on Delicious

---

Buy them at any online book retailer!

Failure or faults?

---

Does software fail, or does it just have faults, or neither?
Silly questions? Not really. I've heard them for years.

Here 's the argument for "software doesn't fail":

Software always works the way it is designed to work, even if designed incorrectly. It doesn't wear out, break (unless you count corrupted files), or otherwise not perform exactly as designed. To wit: it never fails

Here's the argument for "it never fails, but has faults":

Faults refer to functionality or performance incorrectly specified such that the software is not "fit for use". Thus in the quality sense of "fit for use" it has faults.

I don't see an argument for "neither", but perhaps there is one.

However, Peter Ladkin is not buying any of this. In his blog at "the Abnormal Distribution", he has an essay, a small part of which is here:

What’s odder about the views of my correspondent is that, while believing “software cannot fail“, he claims software can have faults.

To those of us used to the standard engineering conception of a fault as the cause of a failure, this seems completely uninterpretable: if software can’t fail, then ipso facto it can’t have faults.

Furthermore, if you think software can be faulty, but that it can’t fail, then when you want to talk about software reliability, that is, the ability of software to execute conformant to its intended purpose, you somehow have to connect “fault” with that notion of reliability.

And that can’t be done.

---

Buy them at any online book retailer!

Resume tic's

---

Want a job in "big business", or want to pursue "gigs" with the big guys?
Here's some resume tic's from the those that know the General Motors' needs:

The "new" GM will want workers who are highly creative and capable of working autonomously as well as collaboratively. 

The future employee will take initiative and have a strong technology background, good communication skills, and project management capability

Well hello! That's a prescription right out of the PM playbook

• Communicate
• Collaborate
• Create
• And, did I mention: initiate!

---

Buy them at any online book retailer!

Multi-lingualism

---

MIT is to open a new College of Computing.
That's nice for them

Of note, however, is this bit from L. Rafael Reif, MIT President, as quoted in the press

The goal of the college is to "educate bilinguals of the future"
And, to be clear, bilinguals are people whose 'other interests' are -- among others -- biology, chemistry, politics, history, and linguistics who are skilled in the techniques of modern computing that can be applied to them

Who said IT guys are one-dimensional? No longer; they can be bilingual
And, by extension, so can the project managers of the world be something other than PM-nerds
We can learn other languages as well!

Better yet: we can be multi-dimensional in both knowledge and wisdom -- what a concept!

Never stop learning is probably the right take-away!

---

Buy them at any online book retailer!

Great project management

---

Give pause to this insight:

"The mark of a great ship handler is never getting into a situation requiring great ship handling"

Admiral Ernest J. King

The paraphrase is obvious:

• The mark of a great project manager is never getting into a situation requiring great great project management

---

Buy them at any online book retailer!

Initiative and independent action

---

From Viscount Nelson, victorious British commander in chief at the naval battle of Trafalgar, we get this insight for initiative and independent action, as described by Admiral James Stavridis in his book "Sea Power":

Nelson knew he would not have clear and instantaneous communication ... [making] precise command and control impossible.
As [Nelson] said in his [planning] memorandum: "Something must be left to chance; nothing is sure ... "
"In case signals can neither be seen or perfectly understood, no captain can do very wrong if he places his ship along side the enemy ..."

So, there's some good stuff there for project managers:

• Don't lean heavily on the idea you will always be in touch when it matters
• Accept the idea that command and control systems have their limits; other processes work also
• Do think it through and commit to a plan -- even though the plan itself may not survive first contact with project reality [some would call this making an estimate .... gasp!]
• Set expectations and then unambiguously delegate authority to meet those expectations

Something to be avoided:

• Nelson was killed in the battle, taking one risk too many 

---

Buy them at any online book retailer!