The Huddle
August 26, 2003
Dave Hoover : Home

A Family

The boy clung to the wrought iron lattice. Perched near the overhanging roof, he looked down at his father. Peter was defiant and in control. With rollerblades in hand, the youngster threatened to get on the roof.

His father Chuck bristled with frustration, spewing a steady stream of threats. Out of a job and run down, his son's antics felt unbearable. The therapists sent here by the county seemed as baffled as he was. Chuck felt certain that Peter was going to need another hospitaliztion. He silently yearned for the boy to do something drastic while the therapists were here.

The two therapists spoke calmly to Peter. Their first priority was to get the boy away from the roof. Over the last two weeks this dangerous behavior had prevented them from moving beyond crisis mode. The therapists' visits to the house alternatively felt like babysitting and law enforcement. It was difficult to see how progress could be made.

Just fifteen minutes before, the family and the therapists had sat together around the kitchen table. Linda gave the therapists her full attention, while her younger son sat quietly beside her. Chuck and Peter were in and out of the meeting, occasionally provoking each other, listening in on the conversation, yet detached from it.

After listening to Linda's softspoken account of the last few days, the therapists asked the family to describe any improvements. As if out of obedience, Linda listed off a few moments of respite, maintaining an impossibly pleasant demeanor as Peter's behavior began to escalate. Attempting to redirect Peter back into the conversation, the therapists solicited his opinion on how they could be most helpful to his family. Ignoring the question, Peter wandered outside, his father on his heels. The meeting was over.

A Team

The young software architect stood uneasily in the morning status meeting. The fear of the pain of his previous project weighed on his mind. He was already seeing the warning signs of another chaotic hackfest. He reported to the team that he had discovered that two different pairs of developers had been working on the same code yesterday. Knowing that the team lead would be annoyed, he was careful with his words as he let the team know that he had merged the code himself after everyone left last night.

As predicted, the team lead's exasperation was clearly visible. The team lead reported what the team already knew: he and his programming partner had spoken with another pair of programmers yesterday about working on the same code. They had planned on merging their changes first thing this morning.

The architect told the team that working on the same files simultaneously went against the version control system. The team lead strongly disagreed, stressing that as long as the team was communicating, it was a non-issue. The architect stated that the communication wasn't happening, and therefore, it was not a good idea. The team lead angrily shot back that the team had communicated just fine, nearly yelling as he told the architect that his faulty assumptions were the problem.

The project manager stepped in to defuse the situation. He told the team that they could continue working as they had been until further notice. A few minutes later, the meeting adjourned.

The Huddle

huddle: A brief gathering of a team's players behind the line of scrimmage to receive instructions for the next play.
The American Heritage Dictionary of the English Language, Fourth Edition
These conflict-filled vignettes illustrate a common practice. Having spent most of my teenage years and early twenties obsessed with playing high school and college football, I'll refer to this common practice in terms that I can more easily explain: the huddle. I believe it maps well onto the life of the family, and as you could probably guess, software development teams.
By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic.
Code Complete, p. 7
Families need to take the time every day to be together as a whole. Without this daily check-in, people lose touch. Family therapist, Virginia Satir, wrote,
It is wise to get together once a day for everyone to touch base with each other. In the busy lives that most of us lead, this kind of meeting needs to be planned. It cannot be left to chance.
The New Peoplemaking, p. 284
In many families, the huddle occurs during breakfast or dinner. Much of the talk is centered around the different activities of the day or week. Significant events at work, extra-curricular activities, and appointments can be discussed and coordinated. But huddles provide more than just a means to work out family logistics. An unspoken connection occurs that melds a group of people into a family.

As a family therapist, I was part of a team of clinicians serving families with youth at risk of psychiatric hospitializtion. We worked with families in their homes to stablize the situation, set up a support system, and transition the family into outpatient therapeutic services. We worked in pairs, also known as co-therapy.

We generally started our meetings with our clients by facilitating a family huddle. It was a chance for the family to reflect on the last couple days, reporting what went well, and what they wanted to improve. The families we worked with were struggling with some serious problems, problems so significant that outsiders were required to help restore the connections and stability that every family needs. Most families do not desire to have outsiders intervene into their private affairs. And most of the time, most families live successfully without any outside therapeutic intervention.

Software development teams have a similar need for a daily huddle. The men who developed Scrum, an agile approach to software development, have this to say about their version of the team huddle,

Scrum meetings do much more for a team than just capturing information. They don't only make everyone capture what they did, but it makes everyone say it in front of everybody else. That way everyone listens to what others are doing and they can offer to help them later. They don't only make everyone say what the issues are, but it makes everyone say it face to face to their management. This forces everyone to have courage and to be honest, and gives everyone a tool to put pressure on management about resolving issues. It also makes everyone promise in front of everyone else what you will be working on next, so it puts everyone's credibility and trust to the test. Scrum is about deep social interactions that build trust among team members.
Agile Software Development with Scrum, p. 106-107, Ken Schwaber and Mike Beedle
As with many successful families, many successful software development teams have a daily huddle. Just as a football team needs to regroup after each play in order to determine their next move, a software development team benefits from the regular connection that a daily huddle provides. Regular huddling forms a collection of people into a collective unit.

Football huddles almost invariably involve all of the players on the field. It is vital that every player understand the plan for the next play. Similarly, it is critical that family huddles and software development team huddles involve all of the players. A player who is disconnected from the team is in danger of being out of position, inevitably facing hardships in the near future.

Coaches

Like families who face difficult problems, software development teams can benefit from outside therapeutic intervention. Norm Kerth calls for retrospective facilitators to be outsiders, people who are free of managerial scrutiny and organizational politics. Similarly, when a football squad is in trouble, the coach calls a timeout and enters the huddle, a meeting usually restricted exclusively to players. As an outsider (a non-player), he can offer insights and ask questions that the players miss in the heat of the game. Software development teams can benefit from a similar practice.

Retrospectives can be facilitated by a variety of people: managers, architects, team leads, or developers. Similarly, football teams have captains, guys elected to lead their teammates. In huddles, on the sideline, and at half-time, captains constantly encourage their team, leading by example. A good coach understands that it is better for captains to rally the team than himself, because it is the captains, not the coach, who are with the players on the field.

When a software development team is in trouble, though, it is helpful to have an outsider facilitate. (See also XP: Call in the Social Workers.) In football, it is in times of trouble or when a different perspective is required, that the coach steps in. This intervention might be a timeout to interrupt the game, or a half-time speech.

An intervention that occurs after every game is the post-game review. After a football game, coaches meet with their players to review the film. Play-by-play, coaches offer criticism and praise, usually reviewing each play several times. A project retrospective is a post-game review, it is an opportunity for the team to reflect and learn.

Healthy Teams

I'm not going to presume to hold the definition of a healthy team, but for the purposes of this paper I will use the following,

healthy team: A team amongst whom ideas, opinions, and disagreements are shared openly and with constructive outcomes. Furthermore, the team contains the collective wisdom it needs to direct itself.
A team such as this, whether it is a family unit, a team of software developers, or a team of football players, will find it possible to operate without outside intervention. I am immediately reminded of an experienced quarterback leading the offensive unit of a football team. When a quarterback has mastered his team's offensive scheme, coaches will often relinquish control to him, allowing him to call the plays. Successful families have been self-directed like this for thousands of years. We have not been as successful at keeping software development teams healthy.

Software developers are faced with evolving requirements, emerging technologies, managerial pressure, and a software development industry that is still struggling out of its childhood. On top of this, teams are generally organized around technical experience and talent rather than the more critical interpersonal skills needed to keep the team healthy.

Working well with others, communicating and interacting, is more important than raw programming talent. A team of average developers who communicate well are more likely to succeed than a group of superstars who fail to interact as a team.
Agile Software Development Principles, Patterns, and Practices, p. 4, Robert Martin
As the team lead for a software development team, I was faced with a difficult situation. The project architect and I were approaching the project from widely different perspectives. He feared the role of the project hero, a role he had not enjoyed in the last project. Thus, when he saw any sign of trouble, he moved quickly, and with an authoritarian style. I, on the other hand, feared that the team would continue its tradition of blindly following directives passed down from above. I was working to help the team find its voice, to be self-directed and self-organized.

The architect and I ended up having several heated discussions in the opening weeks of the project. Daily contact in stand up meetings, occasional pair programming, and iteration retrospectives encouraged us to resolve our differences. After we had lunch together a few times, a mutual respect grew as we began speaking openly about our fears and goals for the project. When you have to continually interact with someone, it is far more difficult to give up on the relationship.

References


Home : Dave Hoover Copyright © 2001-2004 Red Squirrel Design, Inc. All Rights Reserved.