Mar 042014
Agility 2008 May 04

Agility 2008 May 04 (Photo credit: Cynthia Blue)

Mere days ago, Mike Cottmeyer wrote an article called “Managing Risk and Uncertainty in Agile.”  I think the main ideology is captured in the following quote:

I think [treating software as inestimable] is a mistake. If we keep pushing to treat everything like R&D, without understanding the delivery context we’re working within, the whole agile movement risks loosing [sic] credibility with our executives. If you remember from our earlier conversations, most companies have predictive-convergent business models. We may want them to be adaptive-emergent, but they aren’t there yet. We’ll [sic] can talk about how to move these folks, but for now we have to figure out how to commit. (Emphasis mine)

In other words, since most organizations aren’t ready to be agile, we need to ditch agile presuppositions and practices that would make them scared or uncomfortable and treat software development like deterministic work.  He also explains how the metaphor of building a house should inform our understanding of agile software development and what an impact that metaphor has had on his own understanding and practice.  Ultimately, what he wants agile teams to do is give up-front project commitments and estimates.  He (rightly) anticipates that people will say this is not agile, but answers this objection with something along the lines of, “Yeah, so?”

I certainly agree with Mike that just because something doesn’t line up with Ye Olde Agyle Orthodoxye, that’s not a reason to reject it out of hand.  “That’s not agile” is actually not a valid criticism of anything – you have to go on to explain how the idea or practice would hamper agility or has some other harmful impact.  But my interest here is not to refute the practice of up-front project estimates, commitments, or explain the dozens of ways in which developing software is completely unlike a house and why that is a very wrong-headed and misleading metaphor for software development.

My interest is in those emphasized statements: the idea that we have to learn to cater to an organization’s established, outdated worldview and practices until they change into an agile organization – somehow.  This kills me, and it’s disappointing to see it coming from a company that purports to train people in agility and transform their organizations (who’s transforming whom, exactly?).

It’s like that John Mayer song, “Waiting for the World to Change.”  That song has the worst message, which is, basically, “There’s a lot of institutionalized power opposing good social change, so I’m just gonna quit trying until something changes that situation – somehow.”  When you try to shape agility into the old processes and expectations, that’s basically what you’re saying.

Agility is a challenging and transformative force.  It’s meant to create pain points.  It’s meant to challenge processes and how we think about creating value.  This is what’s supposed to happen.  If greater agility is difficult to manage with an existing budgeting process, guess what’s supposed to happen!  The budgeting process needs to be examined.  If greater agility is difficult to manage with your established project management practices, then you need to look at how your PM processes should change.  Agility is something that affects an entire system.  You can’t just agile up a development team, leave everything else intact, and call it good.

So, I call upon agile coaches, consultants, advocates, and well-wishers to challenge rather than accommodate.  Don’t look for ways to make agility more palatable.  That doesn’t mean everything needs to be uprooted all at once, but it does mean that greater agility should be pushing outward to change existing structures, not the other way around.

If you make agility work in the ways an organization is used to, then you’ve made it irrelevant.  You are an enabler.  You are part of the problem.  They have cancer, and you’re trying to get them to smoke a nicer brand of cigarettes.

If you think you won’t be able to get clients if you rock their boat too much, then do us all a favor and let the market naturally select you out of it so people who can actually help your clients can pick them up.  Nobody needs you to institute daily standups and a backlog and allow them to think they’re ready for unbridled productivity.  Some of you are CONSULTANTS for Thor’s sake.  CONSULT!

All of you who, even now, are thinking of how to change your practices around to fit better with older presuppositions forged in an older business environment – all of you who think agility needs to learn to deliver what project managers expect in order to be viable – all of you who think scaling agile needs more command and control – all of you who have never stood up to a client because it’s in their best interests – I call you to courage.  I call you to challenge those presuppositions instead of accommodating them.  I call you to war against high-risk delivery, false and harmful metrics, misanthropic management philosophies, and waste rather than collaborating with the enemy.

As you work with your organizations, ask yourselves, “Am I doing this because it improves the value delivery process, or am I doing this because it’ll work more easily with the way things are?”  In most organizations, if it isn’t subversive, it probably isn’t agile.

Enhanced by Zemanta
May 292012
The Agile Gene, by Matt Ridley (book cover)

The Agile Gene, by Matt Ridley (book cover) (Photo credit: Wikipedia)

Agile coaching is not a regulated profession. There are no baselines for credentials, work experience, or even personal hygiene. Literally anyone can claim to be an agile coach and, given the somewhat ephemeral nature of both “agile” and “coaching,” they can probably pull it off for a long time before you ever got the idea they didn’t know what they were talking about and your projects are falling to pieces.

Being the philanthropist I am, I offer you (free of charge) this guide to determine if an agile coach or consultant is the real deal.

  1. Have they ever actually led a project where they can demonstrate with real numbers decreased lead time and higher quality?
  2. Have they done this more than once?
  3. Can they tell you a story of a time they worked with a client, ran into an issue, made a wrong move, and learned from it?
  4. When they tell stories, are they about actual work experiences (“I was at a client, once, and we…”) or do they sound more like Chicken Soup for the Agile Soul?
  5. Do they use industry terms in discussions the way a squid uses ink, i.e. spray a cloud of it when threatened?
  6. Do they tell that pig and chicken story or that stupid Shu Ha Ri thing every chance they get whether it applies or not?
  7. Do they quote more articles and books than their actual work experience?
  8. Do they say they’ve had “great success” with something, but are then unable to express specifically how that “success” was measured?
  9. If doing Scrum doesn’t magically produce agility, do they say it’s because you’re not doing it right?

Greater agility is something that is a hot commodity, now, and with any knowledge work, the market is glutted with people who are decent presenters with no real expertise. As Troy Tuttle would say, “They’re all hat and no cattle.” They’ve read tons of articles and gotten their certifications, but they have no deep understanding of what it means to be agile, how you measure it, and the common obstacles and pitfalls that teams face and how to work through them.

They don’t understand the principles behind the techniques they know. They don’t have the time in the trenches to weigh against what “should work.” They have no authority of their own because everything they have to say comes from something they read or a class they attended.

These people are high risk hires.

Jul 292011

I know all about business consultants.  I’ve worked with them at many different companies.  I even was one for a while.  For those of you interested in this profession, here’s a quick guide to becoming like 99% of the business consultants out there.

1. Become a massive tool.  Say things like, “Hot enough for you?” and laugh and clap your hands for no particularly good reason.  Ask people with all the passion you can muster if they are truly focused on the customer.  Use sports analogies for everything whether it makes sense or not.  Sprinkle your normal conversation with statements like, “The Internet is a 3 billion dollar pie, now how much of that pie do you want?  We’re gonna ride that pie like a bullet train!”

2. Tell stories, but add no value.  Tell the one about how $90 is for knowing where to tap the engine.  Tell the one about how your job is to move marbles.  Remind people that Bill Gates originally went door to door selling stock.  Thomas Edison failed to invent the light bulb eighty bajillion times.  Plunder Chicken Soup for the Soul like it is a Spanish frigate full of pacifists.  But for Gaia’s sake, do not tie these stories to any relevant points or use them as part of a bigger picture.

3. Just facilitate what everyone else is saying, but offer no content of your own.  The consultant that consults best consults least – at least, 99% of the time.  Allegedly, the consultant is supposed to be the expert.  It turns out that you’re actually the expert, and a good consultant will just help you talk about what you think the problems and solutions are.  I’d say one problem is that you paid out the wazoo for stuff you apparently already knew.

It is for these reasons and more that I loathe most consultants.  I’m even hesitant to refer to myself as a consultant, although that’s sort of what I am, just because the words “consultant” and “useless” are so closely related in my mind due to the sheer amount of experiences I’ve had with them, the ones I know, and the training I’ve received to be one.

So, it was with no small amount of skepticism that I went to a half day session with Sean Stormes on Tuesday.  I knew what he was all about before I even met him.  I had the man in my head, pointing at us and saying, “Are you really focused on the customer?  REALLY?  I’M SEAN F***IN’ STORMES!”

But I couldn’t have been further off.

Yes, he’s Type A, at least in session mode.  Yes, he gestures a lot and uses a lot of vocalics.  Yes, he has a lot of energy.  But despite registering positive on some of the primary This Guy Could Be a Tool indicators, the man offers so much value that it’s unreal, and once you realize that he has an immense wealth of knowledge and is actually going to overturn some of your cherished ideas and move you in new, amazing directions, you find that he’s passionate about his material and a good speaker, but he’s not just a show.

The stories aren’t silly, irrelevant parables; they’re stories from companies that have struggled like you – companies that have lost and won, and how they did it, and how that applies (or doesn’t apply) to your situation.  You have plenty of time to say what you think, but he won’t just affirm it.  He’ll take what’s gold and challenge the rest, and his self-confessed goal is to get you to say the things he wants to say, or in other words, lead you to realize the same things he’s come to realize.

I highly recommend spending some time with Sean Stormes and The Third Door if you want to learn things about your own company that you never knew, and vital things you should know that affects your marketing, message, and processes.  Unless you’re a custom software development shop like AdventureTech, in which case, you should totally pass him by.