Here’s a story of a team that had a serious problem which it didn’t recognize at first. The program manager and agile coach who saw the problem decided not to intervene. They provided space to the team to fail, learn from its mistake, and take action. The story shows that sometimes doing nothing can be the best thing that you can do to implement lasting change in organizations.

Ben Linders, an Agile, development, and management coach, explains in a recent blog post how stepping back and letting a team fail can be beneficial to long-term process and culture change.

While his story doesn’t go into grand detail on the scope of the failure (an hour-long story probably wasn’t a contract killer), I agree with the mentality that a bit of failure (and the burn) can go a long way to reinforcing the benefits of following through and task completion.

These ““soft”” failures don’t tend to make or break a company or a contract, but do tend to stir up emotional responses–especially embarrassment if your team takes pride in its work product and itself.  If not, that’s a team condition that should be addressed immediately. 

EXCERPT:

The program manager of the teams was attending this stand-up. He had worked with the team members as their Scrum master before the team was split into two teams with Scrum masters from the team. He attended this last stand up of the team before the demo, and was unpleasantly surprised to see that the team didn’t take action to finish it. Not being part of the team anymore he decided not to intervene in the stand-up and to stay silent (believe me, that wasn’t easy for him). I saw what happened and also how the program manager reacted and decided to not do any intervention yet.

Should we have intervened? Directly after the stand-up the program manager and I talked about this. He asked me if he did the right thing? I explained him that I expect that the issue of the unfinished user story will turn up in the demo and most probably also in the retrospective. Giving the team a chance to become aware themselves in stead of him telling it is good. I explained that the best solution would be if the team themselves recognizes what has happened, feels the pain, and decides that they don’t want that to happen again. I convinced him that he did the right thing by staying silent, and asked him to wait until after the retrospective. If no team member would bring it up in the retrospective then I would mention it there, as I was coaching the team in using agile practices effectively and become more self-organized.

In the demo, they reported the user story as unfinished. The product owner asked why the story wasn’t finished, which was somewhat embarrassing for the team. I saw how several team members felt anxious about having an unfinished user story in the demo, which could have been done. They came up with an explanation which was accepted by the product owner.

Retrospectives to the rescue […] Next the discussion in the retrospective changed to why the user story wasn’t finished (hold on, now we’re getting to the real problem). The underlying cause was that there was only one team member who knew how to do what was needed, and that team member had been ill for a week. The team learned that they didn’t want to depend too much on single team members. They agreed to do vital few actions, like doing more pairing and peer reviews in iterations so that they would be better equipped in the future to deal with similar situations.

[…]

Doing nothing did solve it!

[…]

Sometimes the best thing to do is to nothing, and remain silent. Trust your people, assume that they are capable of handling a situation. You can follow how they do, and be there to help them. If it takes too long or when a team doesn’t recognize a problem you can still decide to intervene. But it often works better to give people the change to make mistakes, to learn from them and improve.