#ifdef

Over at InfoQ, Geoffrey Wiseman comments on Why Agile Adoptions Fail. It could have mockingly been titled “Agile Fails When Individuals Aren’t Sufficiently Impressed by the Process”. Ironically, many of the reasons he summarizes from Jean Tabaka’s original list blame the individuals involved.

Exactly why should people care about any grand poobah of process? A friend surprised me the other day by saying he wanted to be a development manager. I asked why. He said that as a programmer there is no shortage of people that want tell him how to do his job. But for managers, no one tells them how to do their job. They are only responsible for results.

There you have it. No one wants to be arbitrarily told how they should work. Offering solutions to their day to day headaches will get you respect, however.

Jared Richardson does a great talk on Gradual Agile from his NFJS rotation which he shared with Agile RTP recently. Stealth Agile would be an appropriate title as well. The case study he presents is a great example of introducing agility in a way that wins friends and influences people. One of the golden nuggets in there:

Your agile toolbox has everything in it needed to solve real business problems.

For a long time in our startup, I was slightly embarrassed by never having a “good” answer to the question, “What agile methodology are you using?” The implication was that if it wasn’t Scrum, XP, or some other labeled process, then it must not be agile, i.e. worth consideration.

The thing is though, we intrinsically knew that the Agile Manifesto was the right attitude to adopt for our team. People solutions were favored over process, primarily. We didn’t try to get Ruby/Rails running on a network processor doing gigabit encryption (although once we considered a JVM) to prove agility. We simply applied agile solutions whenever there was a business issue to be solved. Every practice we adopted as a team; unit testing, continuous integration, retrospectives, etc., was a response to a business problem, scaling issue or point of pain in the daily grind.

There were many times that we interacted with customers and certification bodies interested in our “process”. Most of the time, the questions they had were oriented towards waterfall type work flows and artifacts. We’ve never had any trouble mapping our agility to the “best practices” that were expected by these groups.

Rather than boiling the ocean and rewriting from scratch to have a process described in a book, we refactored. Not adopting agility wholesale, but gradually; recognizing that we had problems that could be fixed with agile solutions.

So, how do you eat a hippo? One bite at a time. You can go agile that way, too.