Type I and II

From time to time, it's worth revisiting our old friends Type I and Type II:

In general, a Type 1 error makes you depart from the status quo and take some action that is wrong, while committing a Type 2 error means that you stick with the status quo when you should have acted.

Maintain control
Decision theory is always a trade-off.

In hypothesis testing, you make sure that the Type 1 error is the severe error, so you can control the probability of making it.

As a result, the Type 2 error may in fact have a larger probability of occurring (but it is the lesser of the 2 errors).

Examples:
A pharmaceutical company is testing the safety of a new drug:
Type 1 error: concluding it is safe when it’s not (kill people)
Type 2 error: concluding it is not safe when it is (lose some money)

The criminal justice system:
Type 1 error: convicting an innocent person (terminology: the defendant is guilty)
Type 2 error: not convicting a guilty person (terminology: the defendant is not guilty. It’s important to note that you never say the defendant is innocent).

A scientific researcher
Type 1 error: publishing your research when it’s wrong (embarrassment)
Type 2 error: not publishing your research when it’s correct (usually this means continuing your research until you can show progress)

Important terminology:

• There is sufficient evidence to reject the null hypothesis in favor of the alternative.
• The is insufficient evidence to reject the null hypothesis (NEVER ACCEPT THE NULL HYPOTHESIS – no one is ever declared innocent; they are declared not guilty)

I didn't make this stuff up. I credit a good friend, Dr. Pat Bond, a professor at Florida Tech, for these insights

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Gilb on Agile

Tom Gilb is a system engineer; he is also a project manager and someone with deep understanding of software engineering. His most prominent work is his 1988 book: "Principles of Software Engineering Management".

He is the inventor and thought leader behind an agile-like methodology named EVO (for evolutionary).

In my own book, "Project Management the Agile Way: making it work in the enterprise", I include a lot of material taken from Gilb's work. I like what he says, though frankly a better spokesman for what Gilb advocates is Niels Malotaux: he writes with clarity and simplicity, something that eludes Gilb himself.

Recently, I fell onto a string of Gilb'isms, starting with a 2004 keynote address to an agile conference entitled "What is missing from the conventional agile and eXtreme methods?" His answer, in one word: quantification. And by this he really means quantification of business results, outcomes generated by project outputs, in business terms. He more or less sums up the idea with the words value and quality.

He really takes agilists to task for promoting the idea of a single customer/user as the arbiter of product requirements; instead, agile teams should be consulting--weekly--with the business stakeholders, a diverse group Gilb says can be more than a dozen in any real enterprise.

And, he has heartburn with user stories and other low level practices, like TDD, that he says unnecessarily constrain the inventiveness of developers and leads to "amateur" engineering. Gilb's formula: write down the business quality values on not more than one sheet of paper, and let the developers go from there.

In 2010, he wrote a couple of magazine articles in "Agile Record". The first part, entitled "Value driven principles and values" is a better explanation of what was in the 2004 keynote.  The second part, entitled "Values for Values" builds out his ten principles--first presented in the keynote address--and given also in the first part article.

Gilb's principles are ones we can live by. Here's a reproduction of one version:

As Gilb says of the Agile Manifesto: "it's heart is the right place". Even if you don't buy all that brother Tom says, his heart is in the right place: better quality and value for stakeholders through projects and software.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Building your personal brand

I recently had an the opportunity to address a group of project managers about how to build a personal brand.

Ah yes! The personal brand. And what is that exactly? I told the group: these days, it's whatever the web search says it is. Your identity is more or less your public identity on the internet: it's whatever HR or the hiring manager, or anyone else can find about you as they figure out who you are.

So my advice was: take the initiative. Build your brand on the web yourself and get out in front of the web search. And, there's a lot of ways to do it. Of course, own your ownname.com; and create profiles on the professional network sites that will show up in web searches.

Another idea: have a friend interview you and create your own audio blog. It's cheap and its easy.

And, more, so here's the presentation as available on slideshare.net/jgoodpas:

Building Your Personal Brand

View more presentations from John Goodpasture

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Coming in at 95

The good news: we're still on the Top 100 Agile books list
The bad news: we've slipped a bit from last year. Oh well.

Still, this is the book we're talking about:

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Bow-ties for risk managers

Have you seen this one before? I had not until I was chasing down ISO 31000:2009, the ISO standard on risk management. In a slide show about that, I found this:

The left side is 'likelihood controls' and the right side is 'consequence controls'. Kinda neat, I thought. Certainly, a unique display of a risk matrix.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A touch of madness

Madness! Madness!!

Last two words spoken

"Bridge over the River Kwai"

Sane was the watchword

In several posts, I've made the point that the passionless rationalist will often find it hard to reach a decision. They are wrapped up in the paralysis of analysis--they keep going over all the data and all the alternatives and never reach a consensus--with others or with themselves--on what to do.

My contention, said by many others as well, is that it takes a dose of passion for a vision to break the analysis cycle and reach a decision. And, note this: the passionate have stickiness--once decided, it's hard-to-impossible to move someone off their position.

How many times, on a big decision, have you had an instinctive feeling: this is the right thing to do!  Once felt, there's no more paralysis and there's no more dithering.

That stickiness we spoke of is an elixir to  the follower community: Yes! the leadership knows where we need to get to; there will be certainty and willingness to put it on the line to get there.

Now, I've also written about innovation, and the role leadership plays inspiring the creative to innovate something new to the world.

Along comes a touch of madness

But what luck! Now we learn that there's something that ties leadership and innovation together--something unique when a leader is both inspirational and innovative. In a book that ties it all together, it turns out that truly inspired and innovative leadership have a common root: it is the byproduct of mental disorder and mild manic depression. Who knew? In a stroke (no pun), we've now got the whole picture!

In a new book, author Nassir Ghaemi explains in "A First-Rate Madness: Uncovering the Links Between Leadership and Mental Illness" that some of our best and brightest are just a little mad. Is this surprising?
Perhaps not.  But Steven Colbert was particularly insightful when he asked whether we should be worried that a madman may have his finger on the button (even if only the project button).  Ghaemi said: "That's one way of putting it".  But in his telling, benefits outweigh risks.

God, I hope he's right!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

More about our friend Bayes

When the facts change, I change my opinion.
What do you do, sir?

John Maynard Keynes

In a review of a new book "The Theory That Would Not Die" (S. McGrayne, May,2011) mathematician John Allen Paulos says this:

"At its core, Bayes’s theorem depends upon an ingenious turnabout: If you want to assess the strength of your hypothesis given the evidence, you must also assess the strength of the evidence given your hypothesis.


In the face of uncertainty, a Bayesian asks three questions:

1. How confident am I in the truth of my initial belief?
2. On the assumption that my original belief is true, how confident am I that the new evidence is accurate?
3. And whether or not my original belief is true, how confident am I that the new evidence is accurate?"

In other words, the Bayesian idea is this:

1. Form a hypothesis; assess the probability of its being true
2. Seek evidence that the hypothesis is true
3. Recalculate the probability of the hypothesis, given the evidence (assuming the hypothesis is TRUE) and the probability of finding the evidence

There are some obvious "calibration" problems, the same sort that show up in the risk matrix, and these calibration issues have challenged the efficacy of Bayesian reasoning in the same way:

• It's difficult to get a calibrated probability for the initial hypothesis--what's the benchmark here, and can you be sure that biases are removed?
• It's difficult to find the supporting evidence with clarity of cause and effect
• It's difficult to assess the probability of finding the evidence--again, there may be no historical basis for such a probability.

Nevertheless, according to McCrayne's history, Bayes has these credits:

"It was used to search for nuclear weapons, devise actuarial tables, demonstrate that a document seemingly incriminating Colonel Dreyfus was most likely a forgery, improve low-resolution computer images, judge the authorship of the disputed Federalist papers and determine the false positive rate of mammograms. She also tells the story of Alan Turing and others whose pivotal crypto-analytic work unscrambling German codes may have helped shorten World War II."

For more, see my prior posts.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Stand firm

Be sure you put your feet in the right place, then stand firm

Abraham Lincoln

An example:

In 1862, Lincoln, among other things he was thinking about that year, began to consider adopting a new paradigm involving freedom and citizenship for slaves in certain designated states. This would be a huge culture shift and require deft change management. Not everyone was on-board with the goal or the vision. For some, it was way too much; for others, not nearly enough. Some suggested caution: adopt a pilot program.

These considerations were the result of an emergence in purpose and justification for opposing the rebellion in the southern states: In the first three years of the war--and preamble to war--(1860-62) it was (from the North's point of view) a war to preserve a constitutional union that had no provision for de-unionization. But by 1862, the issue of slavery as it would be in the post-war had come to the fore.  And there was a need to destabilize the threat (of a southern victory--after all, in 1862, the South was winning it all) by fomenting unrest among the slave population.

In debate with his cabinet (a quaint idea in the present White House era), Lincoln decided upon an emancipation of slaves in certain states then in rebellion.  However, Lincoln, ever the decider, decided--and ended the debate.  He subsequently let is cabinet back in to work the marketing and sales rollout.

But, he decided where to put his feet, and that is where he stood!

Lincoln was not a PMP, but nevertheless, there are lessons we can learn.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Are we there yet?

Perhaps we are there!

Mike Cohn takes note of the limitations of the one small colocated team theory of doing software projects, the theoretical underpinning of agile, and the advance of agile methods into the space of larger projects and projects with practical resource limitations:

The early agile literature was adamant about two things: stick with small teams and put everyone in one room.

However, in the years since the Agile Manifesto, the increasing popularity of agile and the dramatic improvements it brings has pushed it onto larger and larger projects.

Additionally, having an entire team--especially on a large project--in one room, or even one building is a luxury no longer enjoyed by many projects.

Mike Cohn
Scaling Agile to work with a distributed team

I for one am glad to see the mainstream agile community get to this place. After all, the community has 15 years of experience behind it:

• Mid-90's early SCUM and XP projects led by a small cadre of thought leaders
• 2001 at Snowbird, UT: Agile--the name--and subsequently the agile manifesto
• 2003-2005: a spate of books by the Snowbird 17 explaining it all
• 2010: my book: "Project Management the Agile way; making it work in the enterprise"
• 2011: here we are!

Mike summarizes his thoughts on scaling and distributed teams in a pdf download of his presentation this past April, 2011 to a user group. To those of us who have looked at the issues and practiced agile in such environments, Mike's points are pretty well known.

His scaling advice more or less comes down to the SCRUM of SCRUMS approach (Mike is mostly a SCRUM advocate/expert),

He has several ideas on distributed teams:
He has a nice pro-con comparison on things like (for the non-colocated team) 'the long telephone call', and offers advice like: make it two calls, the first to set the agenda for the second and set up expectations. That's probably good advice. 

And, like Alistair Cockburn, he says: add documentation back  to compensate for the osmosis of communication in small colocated team rooms.

Also, very telling, about distributed teams: beware that discipline and culture do not port well over time zones (zones are more important than distance: after all, Miami and Montreal are in the same time zone), and across national cultures (where yes may mean no, etc)

So, a lot of advice tid-bits in the presentation; worth a read

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

9-11-11

The Pentagon, Washington D.C.

Ten years later: 9/11/11

Photo

 Bookmark this on Delicious  

Kaplan on strategy

Robert Kaplan and David Norton are best known for inventing the balanced scorecard (and, to some degree, inventing the cottage industry that goes around it and sustains it some 19 years after the original paper in the Harvard Business Review in 1992).

If you're looking for a way to organize a business scorecard, this tool is as good as any.

But of course it also links to strategy.  In an interview, Kaplan said this:

Strategy is a hypothesis. It’s your belief that if you do some things, then some expected results will happen. But it’s only a hypothesis!

And, Kaplan (and Norton) posit five principles for working strategy:

1. Accept that strategy is the job of senior executives. It’s their job to mobilize the organization. They need to understand that managing strategy is managing change and they may need to be the change agent.
   
2. Translate the strategy so that it can be understood. Translating strategy into objectives and, most importantly, into measures is important because measures now become the common language of your strategy.
   
3. Align the organization. This is the most important part of what we do. Here, we create a description of the strategy, convert it to maps and measures and then align every part of the organization to that strategy.
   
4. Make strategy everyone’s job. The strategy is formulated at the top and executed at the bottom, and if people at the bottom don’t understand the strategy, they’re not going to be able to execute it.
   
5. Embed the strategy into what you manage, essentially into your governance, so that your budgeting, human resource, training programs, goals, and incentives are all tied to the strategy.

Frankly, I like the last one best.  It has the best chance of over optimization at the local level if the goals and incentives are pointed to the right objectives.  The four points are good, to be sure, but they smack of a 'chief strategy officer' that is off enforcing strategy everywhere. It's my experience that such activity only lasts as long as the CSO energy level can be maintained waging strategy on everyone.  And, that's not forever, so the best success will come if strategy is part of everyone's management objectives. 

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Leaders and followers

Generals move pins on a map, ... but the front line soldiers have to get the job done

General Eisenhower

Sponsors, stakeholders,and in many situations project managers move the pins. Cost account and work package leaders, and, in the agile domain, team leaders are among the front liners that get the job done.

Leadership is always one of those things on the talking agenda about small team dynamics, and, of course, small teams practicing agile methods.  In a recent discussion, I got this explanation:

Leadership and leaders in small team situations:

1) PROACTIVE 
2) APPRECIATIVE WHENEVER NEEDED. 
3) ABILITY TO KEEP COOL IN TOUGH SITUATIONS AND THINK OUT OF BOX 
4) KEEP THE TEAM BONDED TOGETHER 
5) BUILD A TEAM THAT IS MOTIVATED AND [SIC] TRUST and SUPPORT EACH OTHER 
6) MAKES TEAM MEMBERS BELIEVE THAT NOT ONLY HIGH INDIVIDUAL CONTRIBUTION BUT COLLABORATION WILL BE AWARDED. 
7) TRANSPARENCY WITH TEAM MEMBERS. 

"Ability to keep cool..." .... I like that one, and also "Makes the team members believe ..."

Although the person who wrote the points (above) was not thinking in terms of the traditional "4-E's" of leadership, it's pretty easy to see how they fit:

• Envision: be proactive; look ahead; be confident of the objective
• Enable: keep the team bonded; we're not really going anywhere if we don't go together
• Energize: and motivate with trust
• Empower: with transparency.  Make it obvious and above board, not Machiavellian

Of course one of the ideas in current thinking and theory is the 'self organizing team' and 'rotational leadership'. To the former, I say: works sometimes. The latter, I say: almost never works as envisioned.

In the military, although bureaucratic at the headquarters level, small teams are very agile in the sense of "planning is everything; plans are nothing" (Eisenhower), but there's no nonsense about who's in charge. There can be to question or argument about command authority.

On the other hand, both schemes (rotation and fixed command) somewhat deny the obvious: there are natural leaders and there are natural followers. Leader/followers don't change roles easily, and a team really doesn't work until these dominance stresses work their way through.

In the end, Mother Nature will have her way.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Machiavelli in the project office?

Our friends at Eight to Late had a posting last month on 'actor network theory', or ANT for an acronym. ANT is to my eye and ear a variant of use cases; I'm sure there are differences, but the essential matter of mapping every person and every system as an actor seems to be common among the two ideas.

Actually, however, I'll leave ANT to you to follow-up on. One of the early ANT papers is quoted in Eight to Late, although it's a little dated, having been written in the old timer's era of 2001 about things that happened in the 20th century.  Obviously, no mention Agile.  Nevertheless, late 20th century is also the time when use cases were getting good play, so even though they are not mentioned, one can see the thought synergy.

My interest is in a quote in that reference paper picked up in ETL's post:

They (project managers) either take a Machiavellian view or promote superficial agreement and high sounding concepts while secretly working to their own goals, or they insist on all players subscribing to detailed design specifications expressed in the language of some dominant discourse.

Good grief! So PM's are either cunning and duplicitous, or we torture sponsors and stakeholders into agreeing to words, specifications, and documents they couldn't understand even if they read them.

My experience is that few of us are Machiavellian, but the other charge is too often true. On an ERP engagement I was struck by the futility of the methodology of our engagement partner to get stakeholders to 'sign off on' all the project design documents, as if they could read them (they were in English, but barely so), and more importantly thread them together into a narrative that made business sense.

After all, they (stakeholders/sponsors) were the guardians of the business value; we were the guardians of the earnable value. Our job--not theirs--was to make the translation from our domain to theirs--not the other way 'round. And, that was not the only project where I observed this ineffective sign-off practice. I never understood the value of a signature on a document that I knew was perfunctory and unrepresentative of what it was supposed to stand for.

So, whereas I don't buy the whole quotation (above), I certainly buy half of it! At least agile poses a more effective practice vis a vis the customer/user, even if the close proximity of the customer/user is problematic in many instances.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The virtual team thing

As part of the Agile Project Management course I teach for PMI's eSeminarWorld, I get to talk to students about virtual teams and teamwork since that's how the course is constructed. (disclaimer: I didn't develop the course; I'm an instructor when they need me)

One of the discussions is about what's different about virtual teams; the answers are the one's you'd expect, leading with time zones and 'no co-located stand-up meetings'. But the one I like, though it comes up less often, is 'no body language'.

Having sat on endless conference calls, and participated in a mind numbing number of online chats, I can sympathize that there's a lot left out. But we know that from a lot of experience; we didn't need agile to tell us that body language counts for a lot, by some estimates more than 50%. Agile only reinforces the idea that it's hard to substitute for what Alistair Cockburn calls communication by osmosis--that absorption of information from the unspoken, the casually spoken, and the mere presence in the room, if you will.

On the other hand, reality intrudes: often there's no practical way to get body language in the picture. Yes, that is a shameful segue to video teleconferencing, including Skype and other pc-based video. But I can tell you (as if you need telling) that even with a good camera, video is not an osmosis channel. Nevertheless, better than a straight teleconference most of the time.

Of course, there's the wiki board, and the threaded discussions. They are a possibility also, and I've tried those too. They add value, to be sure, but in the end, there's just nothing like being in the same room!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Filter bubbles et al

So we learned recently that the newest threat to our freedom and liberty is internet filter bubbles. Eli Pariser is pushing this idea (and his book "The Filter Bubble: what the internet may is hiding from you") and you can see his engaging talk on TED.

Now, of course, since his TED talk, there's a whole cottage industry around filter bubbles. Just do a web search on the filter bubble, and a somewhat unfiltered response is returned. A certain irony, there, to be sure.

And there's a counterpoint from academic Paul Resnick who argues that it's not that there is filtering on web searches, including social sites like Facebook--indeed, there is, and has been for a long time--but that the filtering is often done clumsily and ineffectively.

As a project manager, author, blogger, and instructor, I use the web a lot for search.  I use multiple engines to include google, bing, and blekko; and all of these return different stuff.  I also search google scholar, and the archives of many different sites, like slideshare.net, dau.mil, Harvard Business Review, and my local university library online.  So, I may be in a bubble, but I don't see a conspiracy here.

On the other hand, I'm sure there's something to Pariser's theme, more so than book sales.  So, to anyone who relies on just one search engine: you are in a bubble!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.