If you’re looking for a fun way to kick off discussions of difficult topics, then failure bows may work for you.

In September I was at the Agile Coach Camp US (#ACCUS) in Columbus Ohio.  Friday was “Games Day”, devoted to fun ways to engage agile teams with games.

Tobias Mayer led the “keynote game”, and he did a number of great exercises.  Perhaps my favorite was the “failure bow.”  Tobias talked about how we usually feel when we fail at something.  We mope around, hang our heads low, look at our feet, etc.  We tend to pull into ourselves as much as possible, as if we can hide from the failure and from the people around us.

The failure bow is very different.  There are two rules.

The first is that instead of hiding from that failure, we call it out publicly and celebrate.  Tobias taught everyone to stand up and hold their hands up high in the air, as if you were on a roller coaster ride.  Then put as stupid a grin on your face as possible, and say something like this:  “I failed!  This is a learning opportunity!”  You should say it proudly, and say what you failed at.

The second rule is that everyone else in the room should applaud and cheer you when you make this public display of willingness to learn.

This exercise was a lot of fun, and through the rest of the weekend whenever a session facilitator or attendee made a mistake, they would usually stick their hands up in the air, smile with a silly grin, and everyone around would applaud.

I had a great time at ACCUS, and on Sunday as I prepared to leave I considered all the things I learned.  I wanted to apply them to my current coaching project right away.  Failure bows leaped out at me.

On Monday, I had already scheduled a team meeting to discuss a difficult technical topic.  I am helping this team adopt agile automated testing, but they have a very fluid data set and the manual test cycles take a long time.  There are a number of technical reasons I won’t get into here that make it very hard to have a repeatable data set when you test, and so automation has been hindered.

I called together the developers, architects, and testers on the system to brainstorm for an hour.

Because there were a lot of preconceived notions amongst the team about what could and could not be done, I decided I needed to break them out of their mold a little bit.  I wanted to disarm them at the beginning, make it fun, and set a tone that they all had something to learn from this meeting, and they all had something to contribute.

I did this by asking their permission at the beginning of the meeting to try something a little silly.  I explained failure bows, and asked everyone to say something that they didn’t know anything about, and then take a failure bow.  Everyone else had to applaud them.

The team played along great.  I kicked it off by saying that as an outside consultant, I really didn’t know squat about their system.  Everyone laughed and applauded.  Other relatively new team members also admitted in their failure bows that they don’t understand the system all that well.  Others admitted they really didn’t know anything about automated testing.

There was a lot of laughter and applause, and I think it set a good tone for the brainstorming session.  Everyone demonstrated they had something to learn, and I think everyone also heard other people admit areas of uncertainty that they could help with.

I’ll also briefly describe how I facilitated the rest of the brainstorming session.  I set one more rule in addition to failure bows.  No one was allowed to say “No” to an idea, they had to use the “Yes, and …” pattern instead.  This is a pretty common brainstorming technique to try and get people to throw out as many ideas as possible, and not spend their time shooting down other people’s ideas as infeasible.  There’s plenty of time later to shoot down ideas!

As a group, we drew out the current testing process and identified the bottlenecks.  Then I split the room into two halves, and asked each group to come up with as many ideas as they could in the next 15 minutes for how to improve the testing process and tackle the data challenges.

I was impressed with how many things they came up with.  It was a reminder to me as a coach that even though I know automated testing very well, I don’t know their problem domain and ultimately they are going to find most of the solutions.  My job is to help coach them towards those solutions and challenge them when they are not thinking broadly enough.  My job is not to drive them to a particular pre determined solution.

Then each group presented back to the full team, and we did “dot voting” to determine which tasks were most useful to start with.  This led us to four “Next Steps” that we assigned owners to and then posted in the team room.

The next steps list contained items I had not expected, and excluded items I thought would make the initial cut.  It was a better list than I would have come up with alone, and I think a better list than any one team member would have come up with alone.

That’s due in part to setting a good tone for the brainstorming session, and I think failure bows were an important piece of the puzzle.

Thanks to Tobias and Agile Coach Camp for the excellent and inspirational sessions!