Sunday, August 2, 2009

When Agile Evangelism Goes Wrong

After having been an Agile convert from the more traditional waterfall methodologies, I found myself promoting Agile heavily with the company I was working for back around the year 2004. We had successfully implemented our own custom Agile process within our division and had seen great benefits from it. But, there were two other divisions within the company that were still following more traditional, waterfall processes. While I was not in a position to make changes at the other divisions, I knew that the other divisions didn't like the existing SDLC and morale across those divisions were at an all time low. Seemed like the perfect opportunity to move the entire organization to Agile!

So, I thus began my quest to evangelize Agile as the next coolest thing to recursion. I was ready to promote Agile and convince people that it would help them and the overall business. "This should be easy!", I thought to myself. After all, I knew everyone was looking for something better! I proceeded to document our Agile process we had setup within our division and began sharing the document with other product and software managers across divisions. I even distributed copies of it during a product and technology summit. I made it a point to keep talking to other managers about Agile and what it could bring for them. It wasn't long before I was labelled the "Agile Nut" around the office. While I didn't mind the label, what I came to realize is that my approach to instill a grass roots effort to transform the entire organization had failed miserably - instead of convincing my colleagues that Agile could really help the organization, it occurred to me that I may have turned them OFF to Agile instead.

What went wrong? Why couldn't they see the light even when they were all looking for change? It occurred to me that I must have been so excited about Agile being a great way to help transform the organization that people began to see me as more of a crazy, cult-follower of Agile processes rather than someone "sane" that could help introduce the change at the broader level. Yes - I didn't have support from the C level managers nor the managers in the other divisions. While I was able to convince a few of them that Agile would indeed help the organization, it took lots of discussions and in the end, the idea of an Agile organization was abandoned.

Did you catch the key word I used that was the problem? I had to convince my colleagues that Agile would help them. When they were skeptical about the Agile processes I was talking about, I should have forwarded them book and web resources for them to learn about Agile themselves instead of trying teach them myself. It always seemed like a battle talking with my colleagues - constantly proving to them that Agile methodologies would work for them. If they weren't responsive to what Agile had to offer, I should have let it go and ensured that there were resources available for them to learn about Agile themselves. With all the convincing I was doing, I had instead dug a hole for myself in my efforts to convert the organization. After all, any movement toward Agile would have just proved that I was "right" and my colleagues were "wrong" now.

You shouldn't tell someone the same advice more than twice - if they aren't receptive to your suggestions, then it's up to them to learn for themselves. Providing a framework for letting people learn from their own mistakes and giving them the opportunity to learn for themselves is part of what Agile processes is about - and I should have known better to let the management team at the organization realize for themselves what Agile could bring to the organization.

The organization eventually DID decide to make BIG changes to their development strategy by centralizing their development teams across all divisions. With the newly consolidated development division now in place, the Agile strides we had made within our own division had begun to crumble.

Not all was lost though - our division was eventually sold off to another company and I was able to revive our Agile processes for the most part. But, my experiences with the failed Agile transformation was perhaps one of the best lessons in my career in what I needed to do to help make future Agile transformations - or ANY broad organizational change - a success.

7 comments:

  1. Great article; its written in agile spirit of celebrating failure and the learnings that came out of it. Couldn't agree more with the idea that you shouldn't tell someone the same advice more than twice.

    ReplyDelete
  2. Great article, I'm going through exactly the same experience right now and what you say makes great sense. Time for me to back off and let them find out for themselves.

    ReplyDelete
  3. Make sure you have some good Agile books on your desk that will serve as a subtle reminder to others about your past Agile discussions. I'm sure some of them will also eventually ask you about borrowing them if they continue to struggle with their existing process. Good luck!

    ReplyDelete
  4. Great article Grant. It leaves me with the feeling that there were events going on behind the scenes that the business thought were more important than bettering the SDLC (heresy! ;) ). It seems like you did everything you could, including implementing the process in your own group, documenting, and sharing that knowledge. I admire your persistence.

    ReplyDelete
  5. Enjoy some fun agile videos
    http://www.youtube.com/watch?v=NZyi__N4zBo
    http://www.youtube.com/watch?v=nvks70PD0Rs

    John

    ReplyDelete
    Replies
    1. Hi John. I make no claims that Agile is for everyone! In fact, there are certain projects where Agile isn't an appropriate methodology to use. For example, any project that has a high amount of external dependencies that the team does not have control over is something I'd hesitate on using an Agile approach for. See my post about 8 tips to help your Agile team succeed. I challenge teams/organizations to adopt practices that make sense for their specific needs by learning how each methodology, including those in waterfall, help with certain needs and create an approach that works for them - but to always evolve them and never settle for the status quo.

      Delete
  6. Refreshing article. Evangelizing from within is difficult. Everyone knows you and so you do not have the "outside expert" credibility. So I agree you have to work harder to provide a means for people to read, learn, and come to their own conclusions. on the other hand there are practical things to do which maintain objectivity without compromising the momentum. An objective internal proof of concept with clear success criteria and reported results is a great way to capture verifiable results that the organization finds meaningful. The POC speaks objectively. You can be the organizer and facilitator. Involve others. Just some thoughts for this good page of thoughtful comments. I appreciate your openness Grant....nice job.

    ReplyDelete