Touchy Feely Impediments to Agile Adoption

Posted by Mark Levison on Aug 08, 2008 09:24 AM

Community

Agile

Topics

Adopting Agile ,

Agile Techniques ,

Leadership

Tags

Coaching and Mentoring ,

Management ,

Culture Change ,

agile2008 ,

Complementary Practices

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.

Amr presented three models to help us understand what is happening in some of these cases. Christopher Avery’s “Responsibility Process Model”, Roger Martin’s “Responsibility Virus” and Chris Argyris ’s “Ladder of Inference”.

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”.

1. Back to top

   Right on the money.....

   Aug 10, 2008 10:55 AM by Damon Wilder Carr

   Thanks for this. I am quite impressed by Amr Elssamadisy and his work in this area.
   
   I agree he is covering the key issues and offering great value by showing models to help us conceptualize solutions.
   
   Indeed this is where I live most of my life as an 'agile consultant'. It's all cultural/human factors just like it's always been, but Agile makes this vastly more explicit.
   
   
   Damon Wilder Carr
   blog.domaindotnet.com

   Reply

2. Back to top

   Re: Right on the money.....

   Aug 11, 2008 9:19 AM by Mark Levison

   If you liked Amr's work then Joseph Pelrine's will also interest you. I wrote about it: http://www.infoq.com/news/2008/08/coaching_teams and http://www.notesfromatooluser.com/2008/08/coaching-self-organizing-teams.html

   Reply

3. Back to top

   Re: Right on the money.....

   Aug 11, 2008 12:07 PM by Amr Elssamadisy

   I am quite impressed by Amr Elssamadisy and his work in this area.

   Thanks Damon :) As Mark indicated, Joseph Pelrine is quite ahead in this part of Agile. These underpinnings of any successful Agile adoption are beginning to be addressed by quite a few people at Agile 08. I'm looking forward to seeing and learning much more as we start to bring in expertise from different domains that are focused on human relations.

   Reply

4. Back to top

   Re: Right on the money.....

   Aug 11, 2008 12:16 PM by Amr Elssamadisy

   Thanks for this post Mark! Here are some more resources that we came up with as a group:

   1. Clear Leadership: How Outstanding Leaders Make themselves Understood
   2. The Seven Principles for making Marriage work. (This was not explicitly discussed in the presentation, but comes from the world of family therapy and is based on >20 yrs of experimental work.

   Reply

5. Back to top

   Let's use neutral language

   Aug 14, 2008 12:37 PM by Christopher Avery

   Hi, I too appreciate what Amr is doing in this area. And for full disclosure, I'm the Responsibility Redefined™ guy whose Responsibility Process material Amr presented. I'm grateful for Amr's interest and promotion of this important discovery.
   
   My concern is with the continuing use of titillating language like "touchy feely" to refer to the critical human element of work. I'm sure I'll sound like the PC-police here. I find the phrase itself implies that someone smart and accomplished shouldn't have to pay attention to their own and others humanity in order to accomplish their job -- and we know that couldn't be further from the truth.
   
   Even the "hard" skills versus "soft" skills language contains elements of this one-is-better-than-the-other meaning behind the words. For more on this see my blog post.
   
   The language I find useful and recommend is "dynamics" versus "mechanics" where dynamics refers to the human interaction and cultural elements of agile adoption, and mechanics refers to the tools and processes. And what I think many of us are trying to say is that the mechanics of agile don't work very well without the dynamics of personal (and cultural) agility.
   
   Christopher Avery
   ChristopherAvery.com

   Reply

6. Back to top

   Re: Let's use neutral language

   Aug 19, 2008 9:27 PM by Christian Gruber

   I think you're right, Chris, though I expect that at least a sub-conscious part of Amr's title selection was that the term "touchy-feely" is commonly used to describe those human aspects of Agile, as opposed to the lean/science/metrics/efficiency parts. And using the term in this context was, I believe, a bit provocative. But your point is quite well taken. Further, we need to defend that which uplifts humanity, and this sort of work returns human concerns (of culture, personality, relationship) to what is often a sterile industry.

   Reply

• Older >