Touchy Feely Impediments to Agile Adoption

Posted by Mark Levison on Aug 08, 2008

Sections

Process & Practices

Topics

Agile Techniques ,

Leadership ,

Adopting Agile ,

Agile

Tags

Culture Change ,

Coaching and Mentoring ,

Management ,

Complementary Practices ,

agile2008

Share |

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

RelatedVendorContent

Transforming Software Delivery: An IBM Rational Case Study

Kanban for Agile Teams

18 agile and lean practices for effective software development governance

Agility at scale, become as agile as you can be

Five Key Practices to Agile ALM

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Right on the money.....

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

   by Mark Levison

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

   Reply

3. Back to top

   Re: Right on the money.....

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

   by Amr Elssamadisy

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

5. Clear Leadership: How Outstanding Leaders Make themselves Understood




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

</ol>