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.

The “High Performer” high-wire act

Great post by Mike @Figliuolo that points out the pitfalls of hiring in high performers.

More often than not, however, we hire for all the wrong reasons and never think beyond our immediate needs for hiring that superstar. When we do so, all we’ve done is arm the timer on an employment bomb that will go off in our faces.

I’ll extend Mike’s remarks by sketching  out how that bomb works.  As he notes, we can tempt ourselves into a hire for “immediate” needs.  What this can lead to is a transactional relationship with the high performer that spirals downward quickly.

Short-term thinking leads to a star being brought in as — and treated like — a consultant.  The focus is on the fire to put out, the project to deliver, the team to reorganize. Promised rotations and exposure are repeatedly delayed for expedience.

She’s disappointed, but then adjusts her expectations.  Unfortunately, she now views the role as another notch in her resume and a stepping stone (or detour) to someplace else.  Even worse, her performance suffers as she scouts around for the next gig.

Sometimes the situation is flipped — the high performer could be mercenary from the start — but the resentments and recriminations are preordained if the cycle isn’t broken.

Which brings us full circle to the prescriptions of Mike’s post.

Why I left SAP…”macro” negatives

Second-guessing oneself is a risk when deciding to leave a leading company, so I needed to ensure that I had no regrets when I left SAP.   In particular,  I didn’t want short-term personal or “micro” stumbling blocks to obscure great “macro” opportunities in the rest of SAP.  Unfortunately, there were too many big picture concerns that nagged at me, at least from my less-than-exalted perch:

  • The “Post-Shai” Backlash:  The reaction to Shai’s departure was almost giddy in many quarters, which wasn’t a surprise.  The real surprise was the scale, scope, and snarkiness of the reaction.   A lot of non-Palo Alto folks minimized Shai’s contributions when it was convenient — see Peter Zencke on Shai’s “second tier” involvement with BYD — and blamed him when it wasn’t convenient (e.g, BYD didn’t perform because of NetWeaver). 
  • Condition of SAP’s Product Portfolio:  For those familiar with the BCG Matrix, IMO the SAP portfolio is unbalanced.  Nearly all of the SAP portfolio can be classed as either cash cows or pets.   I just don’t see enough “stars” on the solution horizon. 
  • Confronting the Reality of Business ByDesign:  Speaking of pets, there was way too much happy talk about BYD for far too long.  The funding that was poured into BYD — while SAP increased its margins — came out of the hides of other parts of the company.  

This last point highlights the fundamental doubt I had about the validity of SAP’s strategy: Was it still able to produce “stars” organically?  A “not-invented-here” mindset only works when you’re still able to invent.  It is one thing to miss on product development, it is another to deny the miss. 

 Leo is certainly aware of this issue, but this unwillingness confront reality has continued to spread IMO.   I’m not sure that SAP understands just how much damage it has done to itself by running some sides of the company with a gimlet eye, while other sides seems to be living in the best of all possible worlds.

CIO job rotation and commitment to IT value

Great interview by Linda Tucci at (here) with Richard R. “Rick” Roy, CIO at CUNA Mutual Group about his experiences as a line manager and how they’ve transformed his IT leadership approach.  This passage on a shared sense of urgency struck me:

I think the other thing in operations is the sense of urgency. In your customer service centers, the phone rings and you either answer it within your service standards or not; you either resolve the question within your service standards or not, or pass it on to another level of service.

IT operations has that flavor to it, but when you get over into the application development world, it typically doesn’t. They typically are working on projects that can span months, if not quarters, even years. Trying to drive that sense of urgency is probably the other big reminder for me as I have come back into the CIO seat.

Roy also hints at something PMOs need to do better: maintaining the same pace as the business.  A PMO needs processes that are nimble enough to keep up as the business responds to the market, competition, etc. by “adjusting and going perhaps in a different direction.”

Explaining “Speed vs. Thoroughness” trade-offs

I was asked recently about how to balance quick delivery vs. complete (or enough) scope.  Unfortunately, my initial answer sounded lame even as I was explaining it… I later remembered a better example of how to aim for “quick-but-real” wins while planning and executing broader and deeper solutions to the issues at hand.

Such trade-offs are, of course, the life-blood of managing initiatives.  And, of course, one may will have to spend a bit more in resources to get speed and thoroughness (that pesky triple constraint… here and here).  But there’s also the risk management angle to consider.

In particular, the ability to deliver on both “fast” and “thorough” tracks is essential in organizational or business change projects.  Properly targeted and communicate “quick-but-real” deliverables are excellent responses to the risk of poor or no acceptance by stakeholders.  This approach is a way of buying cheap insurance (I know, I know…insurance is a different response type technically) against much bigger risk impacts down the road.

Well, approach “x” worked for me when I worked at company “y”

Well, these magic beans worked for me at AIG...

Well, these "magic beans" worked for me at AIG...

Pawel Brodzinski had a wise corollary for my original post on naysayers (here).  He puts it well…

The distance between rejecting things you don’t believe in and forcing others to do things you believe in is pretty short.

It is great to bring a successful practice to a new situation, but one had better be ready to answer some basic questions:

  1. Why will “approach x” work for this problem or opportunity?
  2. What about our situation may make “approach x” difficult or not applicable?
  3. How will we resolve, mitigate, etc. the issues and risks implied the “What” question above?

I’ve never seen “solution y” successfully implemented…

Go to the mirror...

Go to the mirror...

There are some assertions — or maybe I should say incantations — about process or solution failures that never cease to puzzle me. One of my favorites is:

In my “x” years of experience, I’ve never seen “solution y” successfully implemented…

I’ve heard this about TQM, activity-based costing, Six Sigma, SAP, Oracle, Java, etc., and ad nauseum. No matter how successful or tested the approach, the person who invokes this formula believes that his/her “say-so” settles the matter.

Now I wonder: do those who use such rhetoric ever consider what they’re really communicating? Because I know what I’m thinking: “Hmm…solution ‘y’ doesn’t seem to work when person ‘z’ is around.”


Get every new post delivered to your Inbox.

Join 9,115 other followers

%d bloggers like this: