Don't Come Out Until There's Blood

My sister and I used to fight constantly growing up. Maybe it was personality differences or maybe sibling jealousy, but whatever it was it certainly wasn't me being annoying. Sometimes it would get so bad that my mother would break out the unorthodox parenting tactics. When she had finally had enough and standard practices failed to quell the argument, she would send us both to one of our rooms and say, "Don't come out until someone is bleeding." Then she would shut the door and walk away. Since the authorization to cause bleeding quickly dissolved the desire to do so, the fighting stopped at once. There was usually some silence and maybe some crying, but we quickly forgot why we were fighting in the first place. Eventually the crying segwayed into the model of teamwork. My sister and I, five minutes prior sworn enemies, began to work together to figure out how we were going to get out of this mess.

I hadn't thought about that tactic in a long time but it recently resurfaced as the unlikely inspiration for a team meeting.

Like every team, my team sometimes struggles to overcome differences and difficulties with working together. In fact, I believe the better a team is, the more these problems come to the surface. So called teams in which people work individually are less likely to deal with these problems. In a recent randori, my team discovered that they were having trouble making progress with the prescribed problem. It was discovered that this was mainly due to too many overenthusiastic chef's in the randori kitchen. The 15 minute retrospective at the end wasn't enough to really unearth the underlying issues and left us far short of a solution.

I ended up going home for the weekend feeling like something was left unresolved, and so this thought occupied my otherwise idle brain cycles. Usually when this happens I spend the weekend thinking or dreaming about the problem. I usually come up with a possible solution and I email it to myself as a reminder for our next stand up. This time though, I decided this was my teams problem, and I am a firm believer that a team can come up with a better solution than any individual. The team may just need some guidance and inspiration to come to that solution. Although I believe this statement, I still find it difficult in practice. In the heat of battle, it's hard to let your team find the way when you're certain that you can quickly shine the light. Unfortunately shining the managers flashlight deprives the team of the value that comes from the search for a solution. That's why this time, they needed to be locked in a room, figuratively of course.

This week instead of our normal code review or randori, I turned the stage over to the team and left them to work out the issues from our last randori on their own. I gave them no direction other than to not allow the problems from the randori obstruct their search for a solution. They used the time to analyze the situation, come up with possible solutions and select one or two to implement.

Based on feedback from the meeting, the following occurred:
At first the they caught themselves falling into their standard patterns, however they quickly refocused and recovered. After digging in a bit they discovered that there was too much dictation of design. The team members all had their own ideas about design and rather than collaborating, they wasted much of the precious little design time they had arguing the merits of each idea. To remedy this, they decided on a modification to our randori rules which controls the flow of ideas, and puts that control in the hand of the driving member of the coding pair.

They also agreed that some of the pairing practices we use in the randori should be extended to our everyday work. The idea of changing drivers on a predetermined time schedule keeps both programmers engaged and is especially helpful in craftsman/apprentice (senior/junior) pairs. As a general rule, the team decided to give up design control to the driver allowing for suggestions from the navigator.

It is a truly satisfying feeling to believe that your team doesn't need you, and then have them prove you right. They came up with a better analysis/solution on their own than I believe they would've with me leading the discussion. This is an important aspect of leadership, knowing when to step aside and let the team lead themselves. In John Maxwell's, "The 17 Indisputable Laws of Teamwork," this is known as "The Law of the Big Picture," and it's defined as knowing that the goal is bigger than the role. In pursuit of the goal, sometimes the leader will lead, sometimes he will follow and sometimes he will just get out of the way.