Why Are Most Agile Adoptions Failing?

Posted June 20, 2013 by Amr Elssamadisy

Most agile adoptions show very little success.  Most teams show only a moderate increase in productivity.  Based on my experience and many conversations over the years, I’d say that only 10% of agile development teams actually reach “high performance” where they are achieving 200% to 500% improvements.  We can do much better than that.  And a key step is examining Agile through the lenses of learning and safety.

So, building on Is it Safe to Fail?, let’s take that question into the agile software development world. Learning is the biggest part of software development, and those teams that can accelerate their learning the most become the most productive.  Agile teams, when they find their rhythm, have the potential to be such teams.  Successful agile teams learn at every opportunity – through both success and failure.  Agile methods leverage one type of learning more than all others – that is, learning through failure.  And to be able to learn from failure, we must feel safe enough to fail.  But here is the catch:

Failure is inherently unsafe and most teams and organizations are not places where we can safely learn from failure.

Here are some common ways individuals and teams do not feel safe enough to confront and learn from failure:

  • A team new to iterative development commits to finishing 5 stories in 2 weeks.  At the end of the 2 weeks only 3 are done.  But instead of confronting the failure and learning from their mistake they congratulate themselves on completing 3 and then have the next 2 automatically go into the next iteration.  Or perhaps they decide to add a week to the sprint to claim success because failure is too painful and unsafe to accept and confront.  The opportunity to learn from their failure is lost and one of the main feedback loops in iterative development is disabled.
  • A team in a meeting are sharing what they are working on, and one developer shares a block that it has been difficult.  Another one scoffs at this and says “I can’t believe you’re stuck on that; it would have taken me five minutes.”  That team member and many others now are emotionally unsafe and will hesitate to share in the future and cover up their difficulties and failures.  Little learning and innovation can happen on this team.
  • Developers on a team are working on multiple tasks and doing their best to reduce work in progress by working on one thing at a time.  Their manager is in a hurry and keeps asking them for status on different tasks.  If it were safe, they would have a conversation with their manager describing their situation and continue on their path.  If they were not, which is often the case,  they will drop what they are doing and work on whatever the manger is focused on now.  The inability of the manager to experience a perceived failure in lack of progress on multiple issues has led him to pressure his team.  And their lack of safety with their manager has kept them from performing the most effective actions for the team.
  • A team fails to improve the quality of their software in an iteration and many defects escape. In the retrospective, many on the team are blaming each other or justifying that they can’t do the right thing because it would take too long.  Their lack of personal safety in admitting failure of a task is keeping them from examining the failure together and learning from it.

And on and on…  In the session at QCon NY I led last week all of the attendees were practicing one form of agile development or another.  The majority of them were not getting great results.  And in a 5-minute exercise, we were able to list no fewer than 20 different situations where lack of safety keeps us from leveraging agile methods effectively. So what do we do?

We in the agile community need to take notice of safety and become experts in making it safe for individuals, teams, and entire organizations.  We need to look both inside and outside agile development circles for our answers.  Here is what I am aware of so far:

  • Joshua Kerievsky and his team at Industrial Logic – of which I happen to be a member – have been working on safety and its applications to software development over the past several months.  Josh wrote a great blog describing why this is so important and is giving multiple Tech Safety presentations.
  • My good friend Steve Peha, an expert in K-12 education and learning in general, tells me that safety is absolutely the first thing a good teacher needs to do so her students can learn.  And the idea of safety is well researched in the education space.  He and I will be writing articles on safety and software over the next several months.
  • Dan Mezick, also a good friend, and author of The Culture Game, devoted an entire chapter on creating and maintaining safety on teams as a prerequisite for genuine and authentic Scrum.
  • Guy Nachimoson wrote a blog discussing different ways he has learned to create software safety and mentioned the work of others in the field moving in similar directions.

So here is what has crystallized for me:

  • Teams new to Agile methods need to be safe enough to be able to learn from failure.
  • Agile methods throw failure in our face at every single turn giving us the potential for accelerated learning.
  • That failure itself makes us feel unsafe and inhibits our ability to learn from our failure.
  • Agile doesn’t come with built-in safety mechanisms.
  • And if we want better results we need to find ways of creating safety as a platform for agile adoptions.

Safety has become something explicit that we at Industrial Logic bring into everything we do – both internally and externally – and I as well as my colleagues will be blogging about our journey and our findings along the way. However, we are one organization in the software community.  This is a call to action – to anyone who is struggling to create great software – to start to see safety in their organizations and to learn to make things more safe and then share with the community so we can advance the state of the art.

  • Pingback: Why are most Agile Adoptions Failing? | Amr Elssamadisy's Blog()

  • Tim Ottinger

    Here you talk about a team underdelivering, and not confronting problems. I’d like to amplify a bit.

    I see a lot of teams underdeliver, and instead of taking responsibility they accept the shame and go on. Christopher Avery has some great material on this. Shame is not responsibility. Shame doesn’t help you change, it helps you avoid changing.

    Likewise, a team produces a lot of defects. As a result, they fix the defects and move on to coding “in the usual way.” Rather than operating on responsibility, the team is operating on obligation. They will play this game of “whack a mole”, fixing every bug that pops up, but will they learn why they are programming in such a way that defects results?

    Safety and Responsibility are closely related.

    To risk-averse (unsafe) teams the course that seems safest is to change nothing and just work harder. Most teams don’t need to work harder, they only need to accomplish more.

    Thanks for this.

    • Amr Elssamadisy

      Thanks Tim for your thoughtful reply. Safety is multi-faceted: safety for us as developers, safety for the managers, safety for the organization, and safety for the customer. And provided on your point of view they may seem conflicting.

      So, if we create safety because we want to protect people we may risk making O.K. to be in blame or shame or obligation. And sometimes ownership feels unsafe.

      Creating safety from one single perspective can make it safe to be mediocre.

      – Amr

  • Guy Nachimson

    Thanks, Amr, for referring to my post!

    Yesterday I wrote another one that’s not theory – it was basically a thank you note for my team, but it is all about safety and it’s results. I’m certain your blogging had something to do to highlight this underlying principle.

    You gave here some good “bad examples”, how things are not safe. I’d like to offer a real life example of positive results of having (at least a meaningful degree of) safety.

    Here is my post from yesterday: http://www.thoughtsofaleanguy.com/2013/06/absolute-teamwork.html

  • Pingback: Does your staff feel safe? | Leading Geeks()

  • Nick

    I agree with the article and probably have been unsafe to others in the past – expressed as annoyance. One old project management setup/trick is the bait and demean. It’s framed by asking a leading question whereby the answer is somewhat rhetorical and then use the resultant answer to setup and frame the respondent without means of a lucid response. It’s happened to me and boy did I feel low. I wouldn’t do that to anyone. I would try and get to a root cause rather than use the response as an emotional lever, command and control style, demeaning …

  • Pingback: Why Are Most Agile Adoptions Failing? - Industr...()

  • Pingback: Why Agile is failing | Many cores()

  • Pingback: Why Agile is failing()

  • Pingback: Los principales desafios de Agile | Agile Thinking()

  • Ella Mapple

    Nice article on Agile !

  • prem

    Agile Democracy has compressed cycle times to sync with each team before it goes to next iteration. So stakeholders and end users need to be interviewed early to determine their needs and ensure that the solution that are developing is aligning to their need.

    A detailed analysis from the scrum team can help to reveal previously unknown needs and expectations of Stakeholders early to help the project team manage their expectations, if needed or adjust the solution to align to requirements. Some or all of the end users may reject the solution sometimes because it doesn’t align to their business needs or sometimes because they’re resistant to change.