Agile Transformation? Really?

“Agile Transformation”: now there’s a search phrase that can keep you busy on Google for quite a while. But what do we really mean by “transformation”? A quick peek in the dictionary tells us that a transformation involves a change in composition or structure, even a change in character. The word “metamorphosis” is sometimes listed as a synonym.

There is no shortage of folks, myself included, who are willing to help you with your transformation. But if you’re pondering going down that path, it’s a good idea to find out if your organization really wants to change before you get in too deep.

Sometimes, you can pull off a stellar performance in making your case as to why agile would make sense for your organization on many different levels, and the answer (sometimes very explicitly, sometimes not) may still be, “Thanks, but no thanks”. The prospect of making changes to an organization’s composition, structure, or its very character can be intimidating, and to some, frankly, just not worth all the fuss.

Transformation, by definition, entails irreversible change. If we latch onto the “metamorphosis” notion, the implications of transformation become even more stark: Butterflies don’t turn back into caterpillars.

A currently popular approach to making change more embraceable is to advocate an “evolutionary, not revolutionary” approach. Here again, though, the words and techniques we choose can’t and shouldn’t obscure the real objective: permanent change.  Slower, maybe, but still permanent. An executive once told me, after I explained this to him, “Well, we don’t really want to become ‘agile’ – just more agile than we are now”.  He clearly wasn’t after a transformation. He just wanted to make a few adjustments.

One way we can avoid failed agile transformations is by first correctly assessing whether or not transformation is really the goal. For many organizations, it simply isn’t – at least not right now. They’re content to try to devise viable “butterpillars”, with all the dysfunction you might imagine in such a creature.

This is not to cast a disparaging eye toward such organizations, as many of us have been down that same road to one extent or another. The point here is that a true transformation has no reverse gear, and that for it to succeed, we must be willing and able to make a commitment to changes that are both fundamental and lasting. Sometimes, only after having suffered the consequences of attempting in lieu of committing is an organization finally ready to do so. The organizations that have made that commitment, in my experience, don’t miss the chrysalis at all.

This entry was posted in Agile Adoption, Agile Development, Agile Management, Agile Training. Bookmark the permalink.

4 Responses to Agile Transformation? Really?

  1. Pragati says:

    Well said Lee!

    In your opinion, how can an organization determine whether they are ready for this transition or not? How have you determined this in the past? e.g are there are questionnaires, quizzes, tools etc. that you use to guage the ‘readiness’ factor?

    Should only top executives be included in this kind of a survey, or a random sample across organizational levels be considered?

    It will be nice to know what you think.

    Thanks..

    • Lee Cunningham says:

      Sorry for the delayed reply. You ask a great question. From what I’ve seen, transforming into an agile organization begins with that organization discovering for itself that what it’s doing isn’t working, and understanding enough about agile to see the possibilities it offers. Buying into both sides of that coin are necessary to stay with it when things are exposed and changes become inevitable. If an organization isn’t there, it probably isn’t ready to be transparent and make adaptations. There are a few questionnaires floating around, but by themselves, they don’t do much (in my experience). A good consultant can do a good job of helping an organization assess its readiness, at all organizational levels. That kind of objective assistance would be my recommendation.

  2. Wayne Mack says:

    “Well, we don’t really want to become ‘agile’ – just more agile than we are now”.

    I believe that quote neatly sums up the issue and the communications disconnect. Business have no desire to be agile, they have a need to better resolve business issues. Telling an executinve that he needs to go through a major business transformation for the sole result of being able to say “we’re agile!” is not going to be convincing (unless the executive merely wants to pad his resume before moving on to his next company). We really need to focus on the latter half of the statement and help make businesses “more agile than (they) are now”.

    Agile needs to be introduced to businesses on business terms. How do specific changes help improve quality, quantity, price, or delivery? Changes need to be introduced in an incremental and iterative manner and at worst do no harm. Nothing will halt an agile initiative faster than a disasterous first attempt.

    We need to focus less on “big bang” transformations to “become agile” and more on actually making improvements for the business.

  3. Lee Cunningham says:

    Wayne, sorry I missed your response — not sure how that happened. I couldn’t agree more with your comments. Without making the business case, we’re asking for trouble.

    What I was faced with in speaking with that particular executive was him not wanting to realize that even becoming “more agile” would require some new thinking, and that picking only the easy parts probably wouldn’t result in any viable change. He was willing to join the health club, so to speak, but not willing to exercise or step away from the donuts. :) He wasn’t willing to make any significant adjustments, yet, he wanted to talk about a “transformation”. For my money, I’d like to drop the word “transformation”, and use “transition” instead.

    In this same neighborhood of thought, in the response thread for “this thought-provoking piece by Mike Cohn, he says, “….I remember that being used in old Scrum vs. Extreme Programming debates where Scrum was concerned the more evolutionary of those two. If Kanban is more evolutionary (and therefore better) than Scrum then I call dibs on the next process to come along–I call it “Status Quo” and it will involve doing everything exactly as a company does now, making it even easier to adopt. “

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>