Monday, September 22, 2014

I say weights and you say probabilities...

Just to be clear: weights and probabilities are not the same concept:
  • Probabilities express the proportion of certainty allocated to each value. Consequently, the proportions all add up to 1.0 like slices in a pie.
  • Weights, on the other hand, express relative strength... as such there is no need to have proportionality among weights unless it's convenient.
We hear these terms used interchangeably... weights when we mean proportional uncertainty; probabilities when we mean relative weights. With context, we usually know what is really meant, but not always.

In marketing and sales, we often hear about probable sales (ok) and weighted market values (ok), but then somehow the weighted market value becomes the win probability... not likely true

And, we see similar usage on the risk register where weights and probabilities get mixed.
  • It's ok to say impacts are weighted by some binary scale (High = 4 x Medium; Medium = 2 x Low)
  • It's even ok to say risks are weighted by their probabilities: risk impact x risk probability
  • But, it's not ok to an 80% probability of this happening and a 30% probability of the opposite happening. If these are all part of the same pie, they may be weighted by a ratio of 8 to 3 for some parameter, but they are not 8 to 3 in probability: 80 + 30 > 1

But wait: the world will not end if these errors are made. On the other hand, let's wipe out ignorance!

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Saturday, September 20, 2014

What are you doing on mute?

From no less a project management tome than "The Atlantic" comes this bit of confirmation that we all know but don't talk about. People on conference calls aren't always paying attention.

OMG! Is that news?

Here's a graphic to make the point
I guess I'm old school: if on mute you'll find me in the top couple of bars... doing email or something else.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Thursday, September 18, 2014

It's faster in the slow lane (?!)

Are we all physicists?

We might be.

This might be another take on the tortoise and the hare, but it's more about flows in projects, whether WIP flows in the Kanban, conventional team throughput, or staffing pressures and policies. And, for the quants among us, there's a bit of physics as well.

Imagine this experience (we've all been there): Driving on a multi-lane highway at moderate traffic volume, everyone is in their place: fast guys are in the fast lanes; slow guys are in the slow lanes. All is order.

Now, the volume builds, and you notice an inexorable shift of volume to the fast lanes: everyone wants to get ahead of the crowd.

Now it gets interesting: the fast lanes slow down with increasing volume but the slow lanes keep on moving... moving in fact faster than the fast lanes! And, as volume builds, the phenomenon is more apparent, until... volume overwhelms the whole system and all lanes move together in fits and starts.

Fits and starts: that's physics, actually. So is the slow lane being faster.

And what are the physics that apply to Kanban boards and all the rest of the flows in projects?
Answer: reflected energy. The load (capacity) can't absorb the energy (volume) being thrown at it, so it throws it back in the form of reflected energy (everyone stepping on the brakes).

Do you have microwave waveguides in your project, or any kind of load-matched transmission system? If so, you probably measure the return loss: energy transmitted but not accepted by the load, thus to be reflected.

And, if the reflections are timed right they create coherent waves (standing waves). Thus, in traffic, and elsewhere, with too much volume being applied, you might be standing still in one place, only to move ahead at the speed limit at another place, then to stop again... ergo, standing waves of coherent reflection.

And, we see it in all manner of project flows... the lesson being obvious... throw more volume at the fast guys (fast team) and eventually they'll slow down until everything they are doing is being done slowly, only to be passed by the less-fast (we won't say mediocre, or anything like that)

In the software business, we have Brooks law [I paraphrase]: Adding people (volume) to a slow (late) project makes it slower (later)

Your job: volume manager. No point in throwing good energy after bad... it's just going be reflected right back at you.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Monday, September 15, 2014

Email anyone?

The office memo has been gone for 20 years, but it seems we're still learning how to email effectively. It's as if all the "memo composition rules" were throw out and not passed down to the email generation.

Anyway, enough whining; here's my FIVE RULES for EFFECTIVE EMAIL (I'm shouting here!)

1. Only one subject per email in the body text
2. Subject line is relevant to subject matter (no generic subject lines)
3. Use key words in subject or body that will be used for search later on when you are looking to recall the email; think about how you would write a SQL SELECT statement to retrieve the email
4. If you reply to an email received on subject "A" but want to divert the topic to "subject B", then edit the subject line to start a new thread
5. Avoid river raft paragraphs (long flowing text without breaks); every couple of sentences should be separated with a space. People read online with a different attention span and reading pace than they read on paper.

Did I say five rules? Think about the sixth: Imagine your email in the New York Times... are you ok with what it says?

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Friday, September 12, 2014

Agile is a process -- or not?

First, the agilists tell us that they are not slaves to process, like their traditionalist brethren are. Agilists are free! And then they tell us that you must, must, must:
  • Release something every two weeks, or four at the outside
  • Have a daily stand-up of no more than 15 minutes
  • Have a retrospective meeting at the end of every iteration
  • and, so on....
And, they tell us, these are not processes but rather practices. A process, after all, has protocol, input, controls, and output.... and these don't?

Nonsense. Agile has process like every other methodology; they may be shorter in duration but they are processes nonetheless

Now comes a really radical idea into agile land: Let's do away with these processes and really be free! No less an eminence than Mike Griffiths, an independent trainer and consultant who is steeped in PMI ACP stuff, who blogs at Leading Answers, has given us this wisdom:
It's not the process, stupid!

Here's the core of his argument:
Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:
  • Sense making – agree information gathering steps and prioritize exploratory work
  • Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting
  • Consensus gathering - collaboratively gain consensus on direction, approach and decisions
  • Prioritization – build mindful to risk reduction and business value
  • Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates
  • Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings.
Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail
Did you read that last point? That's a biggie!

The typical advice is do pilots as the training vehicle... Fine, I agree with that. But Griffiths might say (though he didn't) that the purpose of the pilot is not to train on the process but to train on the ideals and principles as listed above.

Fair enough.. But CAUTION: this stuff DOES NOT SCALE. If you have a few teams of really good people who work well together, Griffiths is probably spot on re doctrine, though I'll be even these teams migrate toward process they define for themselves and work for them.

But, if you're working at scale, you probably need look towards what Kent Beck did when he invented XP: practice and process discipline! Toe the line!

I see this issue in my Agile classes repeatedly as students tell me they intend to trade process doctrine for freedom, whereas what they mean is that they are going to trade traditional process doctrine for a more agile doctrine. For newbies, that's probably a good strategy.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Wednesday, September 10, 2014

Agile cost of value

Everywhere I go I make it clear that agile in the enterprise begins with a business case. I make this point in my books* and blog postings over and over. The logic of this is obvious on its face: if you are going to spend other people's money (OPM) they'll hold you accountable. Accountable for what? That's what the business case is for... to answer that question. And, if your processes require a project charter, you can morph the business case in the charter.

But agile goes a step further: agile asks that the customer/user/product manager be embedded in the project and empowered to interpret the requirements in the backlog: sequence them, give them priorities, and recommend new ones, ones to change, and ones to delete.

So, given that empowerment, what then is the utility of the business case. What happens to accountability?

Actually, and in the spirit of keeping it simple, yet effective:

If the customer/user/product manager recommends changes in requirements, not anticipated in the business case, and these changes are material to the business proposition (cost of value), Agile provides two methodology opportunities:
  • The retrospective evaluation leading to the next formulation of the next iteration's backlog, and
  • The release planning session (or process), leading to production releases to the business.
Beyond these methodology opportunities, each business may have processes to handle business case changes that would overlay the project methodologies.

In each opportunity, the witting and accountable product manager goes back to the business case to evaluate impact to the cost of value, very likely consulting with affected stakeholders. It could be messy of course, and it could delay things, but following the agile principle of provoking change early on, it's really in the job jar of the agile product manager to be pro-active about attending to the business case.

* Maximizing Project Value, Chapter 3, discusses the agile business case
Project Management the Agile Way, Chapter 2, also describes how to build an agile business case

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Monday, September 8, 2014

Adm Rickover on 'good ideas'

Good ideas are not adopted automatically. They must be driven into practice with courageous patience.
Admiral Hyman Rickover

Quoted by Jurgen Appelo

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog