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