Changing to Agile, in an Agile Manner

March 3rd, 2011
A while back I was contacted by a potential client who wanted to “go agile.”  But they wanted to do it in a deterministic manner.  They wanted a plan, complete with milestones and dates–mostly indicating that other people had changed their behavior as dictated by management.

Sigh.

One could make a plan for mass training (aka sheep dip), I suppose.  One could   dictate that by June 10, 20XX, all teams will practicing TDD.  Or that all projects will be converted to backlogs and loaded into agile project management software.

But that doesn’t seem so agile to me.  It seems like it misses the point of learning and adapting; of embracing values; of understanding systems and patterns, how the work works, what’s working and what’s not.  Without considering the WHY behind processes and learning as you go, you are only going through the motions.

Start with understanding the current state, and what problem you are trying to solve by “going agile.”  Understand how the current structures and goal alignments are supporting or hindering the goal of delivering products to customers, and identify targeted changes that will improve that ability. Identify where and you can change the pattern and establish structures that will help the new pattern take hold.

Make a Road Map, knowing that you don’t know everything and can’t foresee all you’ll discover on this journey of change. Describe the desired pattern and the steps that you can currently envision to get there.  You won’t be able to see all the steps. If your initial actions are effective, your culture will be changing. Any far-future actions you described from the driveway may no longer be what’s needed when you are 100 miles from home.

It’s impossible to know everything at the outset when you decide to make what amounts to a cultural change. You take some steps, observe the effects of actions, and adapt, learning as you go.

Deterministic planning fails with complex software systems, and it fails with organizational change. Organizations are far too complex, and we need to plan for adaptation, learning, and the fact that the organization will be changing as the plan unfolds.

10 Comments

  1. Devon Smith says:

    I recently made the switch to agile on my team: http://www.everydayqa.com/2010/agile-development/moving-to-agile-what-the-qa-team-needed-to-learn/

    We have learned a ton a long the way, and found that so much of it was based, as you say, not on practices, but on culture. It has been a rewarding experience and really challenged our team to work in new ways.

  2. If I had a dollar for every time I’ve had to tell someone “You can’t waterfall your way into agile.”

    Change is hard, especially when you are talking about some really fundamental values that many people are not even aware they have.

  3. So True!
    Agility is not about following rituals, and having everything known in the begining. Agility is about embracing flexiblity. Agility is a “Mindset”. And transitioning is a real challenge.

  4. Unfortunatelly question about the plan is the first (and last) question. Get the plan, later a client asking for % of completed vs. expected rollouts, asking for exact day “when we will be agile”.

    Many ‘agile’ coaches support this approach by providing ‘plans on the water’ just to fulfill the expectation and not to tell the true. This way things are just worse and worse as they coach all the industry to continue in old habits. They setup the expectations for agile coaches in very bad position.

    I think that industry still needs more education and evangelism and well known agile persons (like you Esther) and organizations (both alliances?) could only help.

  5. Nice post Esther,

    For years now I’ve been speaking of and blogging on “Using Agile to Scale Agile” and have been evolving a framework for doing so. This approach works quite well as it allows organizations to envision ‘releases’ of themselves described in terms of demonstrated capabilities and competentcies.

    This type of change requires a systems thinking perspective because planning and executing an Agile Transformation in many ways is even more complex than the sofware many of us deliver. So,it only makes sense that such an empirical problem would benefit from an iterative / incremental approach with a heavy dose of PDCA. :-)

  6. [...] post is from Insights you Can Use by Esther Derby. Click here to see the original post in [...]

  7. [...]  Didn’t seem too Agile to me, and it didn’t to Esther, either.  I run into this problem with organizations quite often, and I’ve found that talking about [...]

  8. [...] a bit old but it’s still a good article by Esther Derby (@estherderby) on using an agile approach to become agile. Much better to set iterative goals than [...]

  9. When I contemplate an issue like this, I’m inclined to focus on a few things that aren’t even seen as Agile.

    First, we need to know who the stakeholders are and to gather them (or their surrogates) to establish the initial set of goals. In an hour or two. Perhaps we can pick five goals, but not more than ten.

    Then we need to establish what highly specific measures we will use to evaluate progress toward those goals. In another hour or two.

    Then we need to pick a step size to undertake before we reevaluate progress. In an hour or less. A month is much too long but an hour may be too short.

    Now we can consider what possible initial steps that we might try to complete quickly, perhaps five or ten of them.

    Spend an hour filling in an impact estimation table of how much progress we would expect toward each goal if we devote half a day or two days or even a week trying to accomplish one of the proposed next steps.

    Now, finally, we get to try to make some progress. We are taking baby steps. We expect high failure rates. Quit when our time is up.

    For the first time, we have actual results of teamwork. We undertake an after action review. Should we revise the goals? An hour or less. Should we revise the measures? An hour or less. Should we revise the duration of a step? An hour or less. This could be a stand-up meeting.

    Take a break. Come back in an hour or two with new ideas and make a new list of possible choices that make sense as the next step. Remember that we are trying to learn both how to act with agility and also the reality of the difficulties we should expect to encounter in the real world when we are trying to accomplish something that our stakeholders need.

    Impact estimation. Next step choice. Work. Stop. Review.

    Repeat.

    Is it working? How could we make it work better?

    Do not accept anybody’s demand to “leave us alone, come back in three months, you’re going to love it”. That would be expecting miracles, on schedule. If it ever worked, we wouldn’t be trying to learn to work with agility.

    Guess what gurus I took hints from? I didn’t make this up myself.

  10. Is it obvious that we intend to use the impact estimation table to CHOOSE one of the list of possible next steps to actually attempt to accomplish? It doesn’t matter so much whether we estimate exactly or choose the very best next step, usually. So don’t waste a lot of team time seeking perfection. It won’t help that much anyway.

Leave a Reply

Contact Me

Phone me: +1 612.239.1214

Email me: esther@estherderby.com

Search this site

Sign up for my newsletter

Sign up for my newsletter. I will send you updates about my public workshops, information about human and organizational dynamics, and articles that I think you will find useful.

Follow My Updates on LinkedIn