InfoQ

News

Touchy Feely Impediments to Agile Adoption

Posted by Mark Levison on Aug 08, 2008

Community
Agile
Topics
Adopting Agile ,
Leadership ,
Agile Techniques
Tags
Complementary Practices ,
Management ,
Culture Change ,
Coaching and Mentoring ,
agile2008

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

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

Right on the money..... by Damon Wilder Carr Posted Aug 10, 2008 10:55 AM
Re: Right on the money..... by Mark Levison Posted Aug 11, 2008 9:19 AM
Re: Right on the money..... by Amr Elssamadisy Posted Aug 11, 2008 12:16 PM
Re: Right on the money..... by Amr Elssamadisy Posted Aug 11, 2008 12:07 PM
Let's use neutral language by Christopher Avery Posted Aug 14, 2008 12:37 PM
Re: Let's use neutral language by Christian Gruber Posted Aug 19, 2008 9:27 PM
  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

  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:
    www.infoq.com/news/2008/08/coaching_teams
    and
    www.notesfromatooluser.com/2008/08/coaching-sel...

  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.

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

  7. </ol>

  • 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

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

  • Educational Content

    Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

    Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

    Are You a Software Architect?

    The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

    Agile – A Way of Life and Pragmatic Use of Authority

    The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

    Getting Started with Grails, Second Edition

    "Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

    Using ITIL V3 as a Foundation for SOA Governance

    Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

    Adrian Colyer on AspectJ, tc Server and dm Server

    SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

    Adam Wiggins on Heroku

    Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

    SOA as an Architectural Pattern: Best Practices in Software Architecture

    For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.