Preparing the Agile Kool-Aid

After a long hike at Scout camp, there’s nothing like seeing a cooler with bug juice on tap. It’s even better when it’s real Kool-Aid, not the generic stuff. That first sip’s a step back into childhood…well, except for the fact that you need to wait for all the Scout to drink up first!

“Drinking the Kool-Aid” is another twist on the old bromide “you can catch more flies with honey than vinegar.” In this case, Scouts are notorious for refusing to drink enough water to stay hydrated. Heat exhaustion is perhaps the most common reason Scouts head to the medic, though homesickness and ticks are close behind. A cooler full of Kool-Aid turns that hydration chore into a treat.

The same principle applies to agile adoption. I’ve found that while agile is supposed to get an organization away from “command and control,” it’s often implemented from the top down, with a catechism, and all heretics are burned. Someone, somewhere, gets the bright idea to go agile…and everyone has to follow along. Or pretend to.

Of course, agile is just like any other change program from which you expect transformative results. Just think about the challenges that agile is supposed to address:

[P]roducts developed today are the product of massive capital investments. Product refresh cycles continue to shrink in an effort to be competitive in ever evolving markets. The risk of a failed project must be mitigated. Successful risk mitigation today relies more on benefiting from evolving knowledge rather than seeking to avoid it. — From PM College’s Agile Project Management

Such game-changing results require awareness, understanding, and buy-in from each and everyone on your teams. That’s why, before you dive into pilot projects, software spend, or a large-scale agile rollout, you should begin with a bit of discovery.

I highlighted our Agile Project Management course above because it’s a great way to start. It lets you bring together individuals who are all over the place re: agile: veterans, newcomers, and skeptics. Rather than jumping into a boot camp or selling straightaway to executives, you assemble the key players who will implement and advocate for agile together for an introduction. While you may not come out of that session singing every line on the Agile Manifesto, what you say will at least rhyme. In two days you’ll have moved along incrementally, but clearly, which is what agile is all about anyway.

Oh, and everyone on the team now has a little Kool-Aid in their back pocket…to slip in the naysayers’ vinegar.

Matt Ridley on Gut Feelings and the Writings of Gerd Gigerenzer

Merry Christmas!  Here’s the gift of a little science for all you “gut” deciders. Matt Ridley posted this yesterday, pointing to research that suggests that…

more detailed analysis does not necessarily improve a decision, but often makes it worse. He believes, in effect, that less is more: Extra information distracts you from focusing on the few simple aspects of a problem that matter most.

Just don’t call it a hunch, call it a heuristic.

The pleasures of post hoc reasoning

Niall Ferguson had an excellent short column on the financial crisis in this past Sunday’s The New York Times Magazine (here).  I liked the piece, especially where Ferguson punctures some of the conventional wisdom about regulation vs. de-regulation. 

I appreciated Ferguson’s reminder that we have to be very careful when drawing conclusions, especially when the topic is emotionally fraught.  These days of stress and strain seem to emphasize the cognitive biases most of us are prey to:

Human beings are as good at devising ex post facto explanations for big disasters as they are bad at anticipating those disasters. It is indeed impressive how rapidly the economists who failed to predict this crisis — or predicted the wrong crisis (a dollar crash) — have been able to produce such a satisfying story about its origins. 

The SAP/Oracle Choice re: Integration

With the release of SAP Business Suite 7, the debate about the SAP and Oracle integration strategies has heated up.  Loraine Lawson at IT Business Edge (here) uses two posts by Ray Wang (here) and Dan Woods (here), to contrast the two approaches.

Of course, I agree with Lawson and Woods that the SAP approach is better :-).  I also agree that the Forbes audience — C- or high-level business folks — will eat up the SAP message.  However, IMO, it isn’t quite so simple.  Per a paragraph from Woods’s Forbes piece.

Companies implementing new applications or consolidating many companies must ask which foundation is best: a productized and unified platform for business automation or a collection of products that needs to be integrated. Best-of-breed is another way of saying that the user, not the vendor, is responsible for integration [emphasis mine]. 

My experience is that some firms and industries like to have that responsibility and chafe at having processes “pre-integrated.”  Again, I don’t think that is a great default position — one ends up automating non-differentiating processes nearly from scratch — but many pharma and financial firms in particular have tried to “grow their own.”  It is a legitimate strategy if you are truly creating competitive advantage via custom development and integration.

What SAP has done with the Business Suite and its business process platform strategy is to accommodate that desire to be different.  Enterprise SOA allows such customers to get the benefits of process integration without forgoing the capability to differentiate (by assembling or building enterprise services on top of the platform).

Great post/thread on Mathematics, PM, and complexity

Glen Alleman and a number of commenters contributed to a great thread on math, PM, and complexity (here). 

I try to keep the ideas of complexity “science” in mind when planning strategy and its execution.  In particular, I have a deep respect for the power of self-organization and the need to create flexible rather than brittle management systems.

However, I’m not sure how powerful CAS really is as a theory, at least w/r/t/ project management.  For example, how do its predictions advance my estimation approach beyond what we’re doing w/ probability distributions (e.g., Monte Carlo simulations via Crystal Ball)?  To I really need math beyond that to get “good enough” estimates?

WSJ Interview on “The Experience Trap”

FYI, a Wall Street Journal article (“Dangers of Clinging to Solutions of the Past”) based in part on interviews w/ yours truly came out today (link here, page B4 in the paper).  Thanks to Kishore Sengupta of INSEAD for pointing the WSJ my way and to Phred Dvorak of the WSJ for conveying the perils of experience so well and so succinctly. 

As I’ve noted to a couple of colleagues, it is hard to believe that only 250 words of copy came out of two hours of interview time.  Insert your own joke re: my verbosity here…

PM Quote of the Day — Albert Einstein

Make everything as simple as possible, but not simpler.

PM Quote of the Day — Albert Einstein

Any intelligent fool can make things bigger and more complex… It takes a touch of genius — and a lot of courage — to move in the opposite direction.

Methodology Scaling/Selection Outline

Or maybe I should say “Methodology Scaling/Selection Graphic”… Glen Alleman’s recent post on PM and Agile (here) reminded me to post this picture (click to enlarge) of a slide we use when discussing which methodologies to use for which project.  Note that we do not directly oppose “Agile” vs. “Waterfall” in our continuum.  Sure, SAPScrum is pretty pure agile, but that doesn’t mean that ASAP doesn’t contain agile concepts (e.g., emphasis on iteration short cycles during the Realization phase). 

Also, we’re emphasizing that initiative leaders must be comfortable combining philosophies when implementing solutions, which is why we’re driving program management knowledge out to our general PM community (as implied in the bottom box).

Culture-Driven Complexity

Peter Thomas’s recent comment (here) and his post on developing an international BI strategy (here), reminded me that I had forgotten to post on some interesting dimensions of project and project complexity.  Or at least they’re interesting to me…

This PDF outlines some of the complexity that culture introduces to managing global projects.   It’s nothing revolutionary, but I’ve always liked two aspects of these slides:

1. One slide outlines the cultural dilemnas well: “How does an India-based SAP project manager talk to a Manhattan-based marketing analyst?”
2. Another reminds us that we need to remember that we’re individuals, not stereotypes… and yes, I’m the Paul R. on that slide.