Hi:

I work for a large Telco that has a heavy waterfall Technology Development Process that is used for all software projects. This process is actively managed by an IT quality control group that has strong management support and a strict enforcement process.Recently I argued the benefits of Agile development to this group and asked for permission to try it on my project.
Their response was:
1. Agile development requires business process changes so is out of scope of the technology development process;
2. Agile development would require large across the board changes to the current technology process and is therefore out of scope;
3. There is no capacity to conduct a trial (even though I offered to conduct a trial on my project);
4. Most projects are rolling out packages so Agile does not apply (even though a large number of projects including all those in my area are developing and enhancing software);
Frankly I'm thinking about giving up and going to work somewhere more flexible but I would appreciate your advice on how to argue successfully for the introduction of agile in the organisation.

Any suggestions?

My Reply:First, you might be asking the wrong question. "The best way to argue for agile in a conservative organization" suggests two questionable
objectives:

1-You might not need to find the best way, but merely a minimally effective way. Do you need the best or just a toe-hold that might well be the worst, but makes some forward progress? Remember, Columbus didn't know that he had to sail South before sailing West to reach the Indies. South seemed so wrong.

2-Arguing positions you 'one down', giving the status quo all the power. They just have to say no to disable your potential. An alternative objective: How might I create just enough space to convincingly demonstrate the benefits of Agile approaches to a conservative organization?" I could further deconstruct your objective, but my point is that you'll be better positioned to succeed if you formulate the problem so that YOU have the power and don't have to ask permission or change anyone's mind for them. (This might require some out-of-the-box imagining.)

Second, innovation doesn't usually ask for permission. I know the mythodology claims that the only way to implement an innovation like Agile is to get executive support to align the organization. Interesting fable. Almost never happens that way. Innovation more often results when some dedicated someone decides it's going to be different and starts building an inspired community around the effort. What I call an Organizational Insurgency. Traditional control methods are fairly powerless against a well-crafted insurgency. (Notice how I'm not mentioning Iraq.)

Your post left me imagining Thomas Paine posting a similar question to a pre-revolutionary war discussion group: What's the best way to argue for no taxation without representation in a conservative empire? Wrong question, Tommy. State your vision, attract some partisans, then act. Might get hung. The alternatives are kinda grim, too.

One tactic that has worked some places, no guarantees, is to infect the Quality Control group, which, if they're like all the other quality control groups in the universe, neither deliver quality nor exert meaningful control. What's in your initiative that might delight and attract them? Of course, they'll insist upon compromising your purest vision, but you might well find a positive evolutionary
toe hold together, a starting story, that could begin turning the tanker.

Of course, you could get fired for your benevolence. But then, you're considering going somewhere else, anyway.

My advice: stop looking for the best when a little better (even a little worse) might do. Don't ask someone else for permission only you can provide. There will be plenty of time for the rest of the organization to catch up, once they catch on.

I refer you to the Masters and Slaves chapter in my book, excerpt below, link following.

We have arranged the training-room tables into four rectangles—each with five chairs, two on two sides and one on the end—facing the front of the room. In the back and on the north side, windows overlook the street, where, interspersed with detoured taxis, buses, and cars, a constant stream of trucks carry debris from the remains of the nearby World Trade Center. The background traffic noise leaves us straining to hear each other. A project management workshop started an hour before, and progress has already slowed. The walls are papered with half- completed lists of difficulties, and these glower down like gargoyles over twenty pairs of slackening shoulders as the reality of our project work lives settles over us. A darkening drizzle of rain starts outside, and the room feels uncomfortably warm. Time crawls.

We are considering difficulties, when one student stands, looks at those sitting around a table across the room, and with a gleam in his eye declares, “The problem with you is that you do not properly appreciate the Master-Slave relationship.”

No one shows any sign of surprise, shock, or indignation. A moment of silence introduces a twittering instead, as if he has expressed a universally recognized but unspeakable truth. His comment was a joke, of course. But like all excellent humor, it contained a painfully large portion of truth.

excerpted from The Blind Men and the Elephant- Mastering Project Work © 2003 by David A. Schmaltz - Berrett-Koehler, San Francisco - all rights reserved

Maybe you don't yet properly understand the Master-Slave Relationship. (Hint: The slaves are ALWAYS in charge...)

david

David A. Schmaltz david@projectcommunity.com

Buy my best-selling book The Blind Men and the Elephant
here:

http://www.powells.com/biblio/61-1576752534-0