Touchy Feely Impediments to Agile Adoption

Amr Elssamadisy, author of “Agile Adoption Patterns: A Roadmap to Organizational Success”, ran a session at Agile 2008 that focused on the non-technical barriers to Agile Adoptions. He says “As I got older, I realized that the hardest problems are people problems not technical”.

Amr challenged the audience to define what it means to fail during an Agile adoption, we came up with the following list:

• Doesn’t deliver business value – Almost everyone agreed
• Unhappy Customers – Many people agreed
• Overall no better (quality, productivity, …) than before – Some people agreed
• Stopped using Agile – Most people didn’t support

We defined success as delivering more business value than was delivered in the past. For some implicit in that was creating an environment that people want to work in. Perhaps most important is setting goals as to what the business expects and needs from its agile transition. Most agreed that agile practices are merely the means we use to achieve our goals.

We shared several stories of Agile adoption failure:

• One organization brought in consultants who recommended the client adopt TDD without checking their goals. As often happens for a while after TDD is adopted productivity slowed while quality increased. However in this case quality hadn’t been the clients initial focus and so the adoption failed to meet its goals.
• Another organization brought in a contract development team with a formal statement of work. Working with an agile approach the team developed the product that fit the clients ever evolving needs. When the project was complete the product owner and users were satisfied, but the senior leadership wasn’t. It didn’t meet the statement of work – which was their formal statement of the goals.

Responsibility Process Model

Amr explained the responsibility process using a series of stories (from Christopher Avery’s: Teamwork Is an Individual Skill):

• Blame: You wake up in the morning can’t find your keys. You turn to your partner and say “why did you hide my keys?”
• Justification: you tell a long winded story that says its the universe's fault
• Shame: I'm an idiot, I should be better next time (rarely helpful often destructive)
• Obligation: I have to spend the next week on the road because my boss just called. If we answer this call to often we burn out.
• Responsibility we can make a choice, we can say no and its empowering.

Responses below the line are introverted and internal. Only when you take responsibility can you look beyond yourself and be a model for others. We can take responsibility on software projects. Don't accept statements like “I can't do TDD” instead recognize doing or not doing is a choice. If people act from a place of responsibility and then they own the practice. When people act out of obligation they are less likely to follow through and keep up with the practice they've promised to adopt.

Rachael Davies sees parallels with the work of Virgina Satir, while Christian Gruber recommends the work of Terence Real.

We also discussed the Responsibility Virus (by Roger Martin) as a model. Previously on InfoQ as: The Responsibility Virus Helps Fear Undermine Collaboration. Participants also cited: Kent Beck in Be Yourself Create More Value as an excellent resource.

The final model was the “Ladder of Inference” mentioned in Peter Senge’s “Fifth Disclipine”.