Agile -- what it means

---

Dilbert: We need 3 more programmers.
Boss: Use agile programming methods.
Dilbert: Agile programming does not mean doing more work with less people. 
Boss: Find me some words that do mean that and ask again

Dilbert is a creation of Scott Adams

And so, you might ask: what does agile mean?

How about this?

Agile means getting effective project results even in the swirl of complex and uncertain project requirements, primarily by applying small teams, working collaboratively, to deliver increments of business value, with priority according to business effectiveness, importance, and urgency

Ooops! I seem to have left out anything about process. Is agile a process-free zone? Of course not! No one does anything functionally without applying a bit of process, even if it's only two steps.

My observation -- and personal experience -- with myriad small teams is that they self organize to optimize their self interests amazingly fast, first trying one process -- perhaps a baseline process -- and then quickly shifting to another to find a "local" optimization. Sometimes there's an obvious leader; sometimes it's all for one; one for all.

When/where collaboration improves their lot, they'll readily collaborate. Where it's problematic is when collaboration demands are laid on top-down with no obvious improvement in the local process and no apparent connection to goals or objectives. If the top-down thing is legitimate, then the project leadership needs to get in the communications mode to show how all the dots connect! 

---

Buy them at any online book retailer!

Decisions on auto-pilot

---

[Some decision analysis'] have been going on for long enough that they've built up their own speed and force. ... We call them decisions, but they really aren't. [They are] the sum of so many previous events and determinations that they have a weight that feels like a layer of time

David Ignatius

"We call them decisions but they really aren't".
The worst variety of such auto-pilot decisions is trying to rescue or justify "sunk cost", to wit: we've invested so much that we can't afford to decide anything else but to keep going 

Invested in vain
"Sunk Cost" is the cost already expended for which you can't recover. It's no basis for a decision. Decisions should be made on the outcomes to be had by further investment: the ROI on the future.

Of course, easy to write this; harder to execute. No one wants to be embarrassed or fired over wasted or abandoned effort and cost. No one wants to explain a sacrifice or supreme effort made in vain

Advance in a different direction
But a Marine general in Korea, circa 1950, was heard to say (or so he was alleged to have said): "Retreat, hell! We've advancing in a different direction"

Sometimes that's the decision to be made in spite of "...  a weight that feels like a layer of time"

---

Buy them at any online book retailer!

"Open" risk management

---

To be open
Every text and paper I've read describes risk management like many other project processes: open, transparent, available to any on the project team. Risks are identified, evaluated, ranked, made subject to some form of risk reduction paradigm; and everyone is made aware.

Oh, but if it only were!
Most of us can handle the text book process. It's more will than capability

But, on projects of material consequence, the "real" risk management is not open
The "real" stuff begins when the text book processes have run their course

Or, not to be open
Too often than not, risks are compartmented. Sometimes "innocently" because the related work and scope are compartmented by project circumstances: security; systems partitioning; backlog partitioning; teams and teamwork; virtual teams

Judgments scorned as guesses
Only bring facts! Ooops, there are no facts about the future; only assessments of events, impact, and probability. All the facts are in the history.

No facts? Then you're just guessing, "they" say. So, "they" say: take you guesses elsewhere.

Inconvenient assessments
But, then, of course, there's the inconvenient assessments that need to be "buried". These assessments come to the wrong conclusion or forecast; they are not in accord with company or agency politics. Sometimes it just petty professional competitions

Whatever: of these we can say that risk management is "closed", not open; not transparent; and not available to all who need to know

Bummer !

---

Buy them at any online book retailer!

Who calls anymore?

---

Who calls anymore? Some, but many fewer than before .... unless it's a robo call

It's surely not news that a lot of business communication has moved to the text and email.
Fair enough

But, that leaves much more communication open loop and unacknowledged than is/was the case with the telephone call.
That may not end well. Such open loop communications violates basic control-loop theory. To wit,

to have predictable outcomes, the loop should close on the sender as a means of confirmation of message received.

So now, as non-verbal correspondents, we have the responsibility of upping our game.
Some help is found in the essay "How to get every email returned"

From that essay and my own experience, my advice is this:

• Keep it short!
• Write in bullets where ever possible.
• Don't exaggerate ... when discovered this kills your credibility
• Don't guess; meaning: say only what you know

One troubling assertion in the essay: Emotion is more persuasive than facts.
Perhaps; it depends

I worked for a few years for a Asian company with Asian managers. Culturally, those managers put more emphasis on facts than comparable American managers. In my experience, Americans were/are more tolerant of ambiguity, uncertainty, hunches, instincts. Often, these are wrapped in emotion

One last point, circling back to closing the loop:

• Ask for acknowledgement. Often, the "open-loopers" are unaware of the poor practice of not closing with their correspondent

---

Buy them at any online book retailer!

Understood ... misunderstood

---

The blog at herdingcats provided this little bit of wit:

Don't write so that you can be understood, write so that you can't be misunderstood. — William Howard Taft

Taft has a good point there:

• Not only to be understood (meaning + context) 
• But to not be misunderstood (meaning + context + motivations or expectations)

Not so fast!
It's often not that simple

You want not to be misunderstood:
First, for understanding, start with the three step process for communications

To be understood, steps 1 and 2:
1. Tell 'em what you're going to tell them
2. Tell them

To not be misunderstood, step 3:
3. Tell them what you told them

Second, to avoid misunderstanding, deal with these hazards:

• Missing or ambiguous antecedents (Pronouns should be banned! Be specific with names, as example: Tom and Jerry wrote the report. But there were complaints about the analysis that was done; he should have done it more carefully)
• Big words not commonly understood (intellectual arrogance) 
• You've got in your head, but you don't get it down on paper (and you don't know you didn't get it down on paper)
  Typically the context or connections with prior thoughts are missing on paper.
  The best way to address this missing material: compose the words now and read them a day later .... does the wording still make sense?

You want, or can tolerate, misunderstanding by some, but not all
You don't want your intended correspondent to misunderstand, but it's ok if everybody else misunderstands, even as they seemingly understand.

• In politics: plausible denial (everyone's favorite go-to). The words are understood, even as the intended understanding -- deliberately open to misunderstanding -- is obscure. (Make them an offer they can't refuse)
• In security: You and I have the code for the plain text, but others see and understand the coded text differently.
  As example: Coded text, i.e. what the world understands: "Play the piano"; Plain text (what you and I really understand): "Start the process"
• In command and control: interpretable instructions or vision. To wit: strategic wording written down, but implementing details and interpretations left to others
  (In effect, delegation to the tactician or field commander. But sometimes you let interpretation "live" with the times and circumstances [so-called "living documents"])

---

Buy them at any online book retailer!

Manage the white space

---

You've got a team to manage; until you don't
Keeping the team together promotes cohesiveness, intra-team loyalties, and productivity (no investment required to introduce new players and relationships). But, if there's too much slack -- i.e. downtime or "whitespace" --  you might lose your team.

But, keeping you team begs the question: How to keep everyone busy all the time so as to fend off raiders looking for resources?  In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

Whitespace methodologies
In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

• Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
• Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
• So also bring in mock testing, special event prototyping, and, of course, that bane of all:
• Maintenance of team records.

What does it cost?
One consequence of managing by teams: the cost is known, predictable, and relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each.

Affordable value
Of course, is the team affordable? Many PMs are not comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:

The cost of a project is not its value; in a "good project", value greatly exceeds cost

---

Buy them at any online book retailer!

Risk: the second thing you do

---

Managing risk?
Can you imagine there's risk to manage?

Here's the second thing you do:

• Evaluate the slack ... 

What's to evaluate?

• You might think the most important thing about slack is how much is there; what do I have to work with? Nope
• Whatever you've got, the most important thing is sequence and position. Where in the course of events are you going to position slack so that it works to your greatest advantage?

Slack makes the first thing possible

• We all know that the first thing in risk management is loosen the coupling.
• Slack is the mechanism for such loosening

Where to position slack?

• At the end (of a schedule or task)
• Between joins of physical units (if expansion allowance is necessary)
• Wherever timing is critical

It's not to wasted

Apart from overly tight coupling, poor positioning or sequencing of slack is a resource wasted. And, it will cost you otherwise to substitute an alternate resource!

 

 

---

Buy them at any online book retailer!

Performance; experience; wisdom; track record

---

 “You do not write your life with words...You write it with actions. What you think is not important. It is only important what you do.” (*)

Patrick Ness 
 

What you do adds up
Getting promoted? Hopefully not to your level of incompetence!
Want to get promoted? Most do.

What's needed: a personal track record; as Ness would say: a record of what you do.

• Personal performance over time
• An accumulation of experience
• Demonstration of wisdom

About wisdom and experience

Hopefully, you recognize the linkage of the last two: wisdom derives from experience, but wisdom only derives from the experiences of both success and failure

“By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.”

Confucius

About performance  
Laurie Harvey has an idea on this: KPIs for success , meaning KPIs for personal success as a project manager. In her essay, Harvey makes one big point up front:

When performance is lacking, everyone knows it; when performance is on par, it may not be noticed .... until it is.

KPIs for success
So, what's par for the PM? What goes into the personal track record?
Harvey looks at these as instrumental to a winning track record, stuff that will get noticed over time

• Delivery according to expectations
• Budget acumen
• Process improvements
• Relationships and communication
• Risk management
• Customer orientation

And for the MBAs among us
Harvey's list is all good stuff; all project oriented. If you're going for a big promotion, my advice: Add to Harvey's list your competence with the business side. A good place to start is the Balanced Scorecard -- Measures that Drive Performance. But that's another story.

-------------------
(*)  Another way to express Ness' idea: Be consequential!
But consequential actions could be writing (consequential writing is an action, in spite of Ness').

---

Buy them at any online book retailer!

The core of knowledge

---

... statistics is what tells you if something is true, false, or merely anecdotal; ... it is the instrument of risk-taking

Statistical and applied probabilistic knowledge is the core of knowledge;

Nassim Taleb

You got to hand to the guy: he is passionate about his subject.

Of course, he's also the first person to tell you that his most infamous invention, the "Black Swan", is black - - that is, extraordinarily rare - - because there are no statistics to predict it.

Statistics in the PMO
Two of the more useful properties of statistics are these:

• They are are surrogates of a past track record; thus, handy for estimating
• They are persistent in the sense that they are survivors: wait weeks or months and if the circumstances haven't changed, neither have the statistics. Thus, your story doesn't change with time, an idea called "stationary".

Rules of thumb
For project purposes, rules of thumb may be as useful as actual statistical analysis:

• There's shift-right bias at milestones; milestones are inherently weak objects in the schedule
• Diversification follows the "square-root-of-N" rule: diversify into 4 independent events, and get a 2:1 improvement in risk (square root of 4 is 2)
• "Expected value" -- which is a risk weighted average -- is usually more pessimistic, and therefore more conservative, than "most likely" value" (the single value with highest individual probability)
• "Expected utility value" is not objective, and subject to many biases (utility is a weighting according to usefulness)
• Independent events tend to centrally cluster--the theory of central tendency
• A sample of a large population can be an economic approach that saves time and money

---

Buy them at any online book retailer!

Showing confidence

---

Making a presentation?
Speaking to a large group?

Are you confident?
Yes? Good show! Hopefully, your audience will think so also.

Mike Clayton has a helpful posting about behaviors during your presentation that will go along with projecting confidence to your audience. Helpfully, Clayton says it takes less than 2 minutes to read it.

Here are two ideas I like, especially the first on about hands. I've personally made that a "must do" and its proven very helpful

Hands
Keep them still. Fight the fidget. Take everything out of your pockets (if you have them) to avoid the temptation to play with them. And if there's nothing in your pocket - don't play with it.

Pace
Slow down. Nervous people hurry. With speakers I also talk about the power pause, to get and hold attention.

TED-talks: See this stuff in action. View some TED-talks and watch for the confidence projection techniques. You'll find Clayton's advice is universally practiced.

---

Buy them at any online book retailer!