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.