Yesterday I was working with a group that was struggling with the balance between product owners and developers. It wasn’t an “Us vs. Them”, but a common tension that I’ve observed on teams working to get real results out of agile practices and processes. This particular team was using Scrum and we were discussing the question of when to review work during an iteration. Should the product owners wait until the end of the iteration to review the work? Or should they be reviewing work during the iteration as it gets completed? And what happens if they find something that doesn’t meet what they need?

In this particular situation, developers were often upset when product owners reviewed things that were still in-progress because “they weren’t ready yet.” They wanted product owners to hold off until they – the developers – said it was “ready for review”. The product owners, on the other hand, wanted to review things early so that if developers were going down a blind alley, they could tell them early on. Also, if there was a mistake – on either the product owner’s side or the developer’s side – that it was caught early and we didn’t spin our wheels working on something that would eventually get thrown out.

This is not an unusual situation. This particular scenario is one of the common reasons many teams find Kanban so attractive – because the artificial time-box of an iteration seems to keep us from doing the right thing and recognizing and responding to change early and often. But I wonder if this particular problem is not related to iterations at all.

In fact, I’m going to suggest that the root cause is the lack of feeling of SAFETY in and on the development team. Let me take a few steps back to explain:

I’ve been lucky enough to be on several high performance teams in my career. And these teams are phenomenal – they  are significantly more productive than your average development team. They do much better work from many points of views: quality, time to market, visibility, etc…. They also enjoy their work much more.

These teams are great at software development which means that they are extremely good at learning from failure. They use agile methods to build software, get feedback early, and respond to that feedback accordingly. A large portion of that feedback is based on failure: writing software that fails tests and gets fixed, building features that don’t meet the user’s needs and has to be re-designed or completely trashed, putting in technical solutions that don’t scale, and hundreds of other issues that come up. Those teams don’t get caught-up in the potentially draining tensions and stresses associated with failure.

Why not? What is special about these teams that they are resilient to the dragging and draining effects of failure – let alone regular and repeated failure?

You probably won’t be surprised to hear from me that I don’t have the entire answer, and the answer I do have falls into three categories: agile practices, individual human dynamics and culture.

Let me explain further. Failure – for most of us – is not an enjoyable experience. However some of us have become good at it. And the major reason behind this is SAFETY. If we feel safe to fail, and are rewarded for it regularly, we can find ways to fail fast and learn quickly.

Here’s what I’ve experienced and observed in teams that have the skill of failing fast and often and learning from those failures:

1. Leaders create a culture that rewards small failures and the successes that come after them. They celebrate the successes and failures and lead by example.
2. Individuals understand that failure is a milestone the road to success. They have experienced it multiple times and are not intimidated by it.
3. Teams use software development practices that make failure SAFE.

Let’s look at #3 a little more closely. Consider different types of failures: failure in private and public failure. Failure in private is much easier to handle (although still not easy). Also consider that small failures are less overwhelming than large failures. A small failure is easier to recover from.

Now let’s consider some concrete practices that make it safer for us to fail:

• Think of test driven development (TDD). How much easier is it to fail privately at your desk with a red bar, fix it, and then check in working code? How much less intimidating is it to find a mistake after a few minutes of work than a few days or weeks? Also, the other half of this coin, is the success and frequent, small celebrations of success when a developer sees a green-bar indicating tests pass.
• Think of test driven requirements (aka TDR, automated acceptance tests first, behavior driven development/BDD, etc). How much easier is it to work incrementally with some FIT or Gherkin tests to make them pass and fail at the privacy of your own desk than it is for someone to manually review your work with you and point out your mistakes (or even worse, in the middle of an iteration demo with execs looking on)? Also, just like TDD, a passing test is a celebration of success.

The complaint from developers in the beginning of this blog were about product owners calling out their failures early and often. It was painful for them to have these issues brought up in public.  However these conversations with product owners have the potential of accelerating the learning of the team and thus accelerating their performance. The same developers on a team that practice TDD and TDR have fewer of those circumstances happen yet get the same feedback because these failures happen at their desk.

So, in the end, one of the best ways to encourage the learning from failure practice that is always found in high-performance teams is to make failing safe AND to celebrate successes. We can do this on multiple levels: at the cultural level, at the individual human dynamics and mindset, and with the software development practices we use. A few agile development practices are extremely good at this, specifically test driven development and test driven requirements because they allow us to fail privately and create small reward loops where we constantly celebrate small successes.