A Brief History of the Team Huddle
This article is part of a series about Huddles and an excerpt from my book in progress “Huddle, the hidden power of the stand-up meeting” published on Leanpub. Feel free to share your feedbacks!
The sign language issue
Every person who has ever played or watched a collective sports game knows what a Huddle looks like. Broadly used in many sports, the Huddle takes the form of a tight circle where teammates strategize, motivate or celebrate. They often end with a “war cry” that act as an energizer for the Team. What the Teams did before the Huddle exist I honestly don’t know. But I know that this ritual always produces the same effect on me. The war cry, the feeling of individuals being part of a bigger whole, the energy and incredible desire to win that results for the Team always fascinates me. So, when I started to dig deeper on its origins, I was amazed by what I discovered.
The practice originally comes from a deaf Quaterback [Wacker, 2009], Paul D. Hubbard who played American Football at Gallaudet University in the early 1890s. He and his teammates used to gather regularly during the game to discuss strategy, like in any other sports Team. But they were facing a big issue: they had to use deaf sign language and it was really easy for the opposing Team to catch key informations just by observing them. One day, Hubbard had an idea that changed sports forever, he asked the Team to line up in a circular formation so everyone could exchange information and put a strategy in place in absolute privacy. These were the premises of close Team communication and self-organization around a common goal: victory. Over the years, the contents evolved but the form remained the same and became a key Team event in many sports.
This kind of Huddle is far away from what we can see in our business context. However, not so many Teams reach that unity that characterize sports Teams. They lack the Team spirit, they lack the energy.
A day at the hospital
In another field of activity, evidences of a “morning report” were found in several articles about healthcare during the early 1980s [Amin et al., 2000]. Taking the form of an “almost-daily” event that lasted for about one hour with the participation of all the residents, the morning report was originally a status meeting used by chieves to oversee the activities of their service. The information flow, here, started from the bottom and went up to the hierarchy, so they could ensure the health and safety of all the patients.
Over the time, the meeting evolved and became a key-event for peer-to-peer information-sharing in the day-to-day management of a hospital. Studies show it served five different purposes, the main one being education. By sharing case informations and approaches, and how they managed their patients, residents were able to teach and learn various skills from their peers, including topics that were not part of the curriculum, such as ethics or decision-making and developing curiosity. In addition to informing their peers, they could discuss and brainstorm — in other words, use the collective knowledge and intelligence — to solve complex cases. A particular attention were paid to the detection and reporting of adverse events such as drug reactions, increasing both the quality of service and the collective knowledge. Making residents talk about their approaches were also a good way to get peer evaluation of their performance, giving them precious feedback to improve themselves. Various discussions about non-medical issues could happen on a regular basis such as ethical, political, economic, cost-effectiveness or administrative topics, allowing everyone to speak up of sometimes taboo subjects. And maybe a less obvious purpose but as important as others was that people were able to socialize during these events. Drinks and food were served to maintain an informal atmosphere and busy people could take time to meet with others.
Concerning shifts and patient handoffs, however, they seemed not to be driven in a sufficiently formal way until the Joint Commission Center for Transforming Healthcare took care of it in 2009. There were a high rate of patients coming back due a bad transmission of information and a low satisfaction rate from both families and residents. So, the Commission began a project to improve communication during handoffs by applying Lean principles in pilot hospitals. They provided them with a tool to manage their handoff improvement project where they could previously be either formal in a tool or a sheet of paper, or informal by oral. Hospitals didn’t have to change anything in staff composition. They just had to form a dedicated Team that could take time to analyze data from multiple sources, gather the needs for information of all the personnel, analyze and treat problem root causes, to finally align everyone on a clear handoff process. Just a few minor changes were added to the existing roles and responsibilities, as always, the problem was not a matter of competency, nor people, just bad communication.
Interesting how a small change in the way people communicate can lead to decisive results (I could have said “life-saving”). As a coach, a big part of my job consists in helping people improve their communication skills. It is not just about Agile or Lean techniques or practices, the foundation is always communication. When people start to care about how and what they communicate, and to whom, especially for informal communication, a big step is made. Trust is being built and everyone start to really care about the system.
The dawn of agility
Back in the early 1990s, as part of their work at AT&T Bell Labs, James Coplien and Jon Erickson developed a technique to visualize and analyse organizational dynamics [Coplien et al., 1994]. After several internal tries at AT&T, they want to test the validity of the methodology and learn from other organizations.
“One goal of our research is to correlate these patterns to high productivity, quality, and responsiveness in the organizations that generate them. By understanding these patterns, we hope to develop principles from which new, highly productive organizations can be built” writes Coplien.
Amongst the results of their several experiments, one Team standed out from the crowd: the Quattro Pro for Windows development Team. The core Team was only composed of four people (later extended to eight) and each developer produced more than 1.000 lines of code per week during the 31 months that lasted the project. They worked iteratively in intense interaction to define, build and test early prototypes. Shared QA and testers when needed at first, but eventually became part of the Team as the software grew.
Have you guessed what their secret sauce was? Frequent synchronization, collaboration and coordination. They centered all their development activities around daily meetings where they discussed about architecture, design and interface. They exposed what had been done so far and what new knowledge had been gathered (synchronization), discussed the best solutions to address the needs of the product (collaboration) and planned the implementation that would be done privately by each individual (coordination). People in the Team knew everyone would do a terrific job. There were all experts after all! Of course, as they were working on the implementation, Team members often discovered changes were needed at the architecture level. So they just brought up the subject during the next daily meeting, make decisions, adapt the plan, and so on… They were self-organizing around the work to be done. And they were transparent to each other.
It had huge consequences on the Team dynamics, like a virtuous circle. The high level of trust made them accountable to each other. Frequent collaboration increased the quality of the system. The communication saturation and deep understanding that resulted allowed them to take real ownership on their day-to-day work and led to a more even distribution of effort across the different roles. All of this reinforcing the Team cohesion and energy.
“We are satisfied by doing real work. Software is like a plant that grows. You can’t predict its exact shape, or how big it will grow; you can control its growth only to a limited degree” said Charlie Anderson, one of the QPW architects
This new way of working, coupled with Coplien’s works about Organizational Patterns inspired two of the most used Agile Software Development frameworks: Scrum and Extreme Programming.
The first Scrum Team
Remember, at this time, there was no such thing as “Agile software development”. Still, several thrusts were happening simultaneously across the (IT) world. Jeff Sutherland was one of those visionaries leading the change and was building step by step what would be soon known as “Scrum” (as well as Ken Schwaber and Mike Beedle, the other Scrum co-creators). To the Team he was in charge of at Easel Corporation [Sutherland et al., 2014] (the first Scrum Team), Jeff showed regularly a video of the All Blacks’ haka. If you are not familiar with this ritual, I strongly encourage you to watch their performance. Very troubling. Before every game, the whole New Zealand rugby Team gathers and performs an impressive Maori warrior dance.
“While watching it, you can almost see the energy come out of each player and coalesce into a greater whole. With synchronized stomping and clapping and chanting — ritualized movements of cutting an enemy’s throat — you can see ordinary men transform themselves into something bigger, something greater. They’re invoking a warrior spirit that does not accept defeat or dismay” describes Jeff Sutherland about the haka.
The Team was already using iterations (called “sprints” in Scrum) to develop on cadence but it was not enough to efficiently manage the risks. They needed a more often event, they needed a heartbeat. Looking for a way to improve their self-organization, they decided to combine the haka spirit with the kind of daily meeting that the QPW Team was doing. They watched the video over and over again and came up with four aspects they wanted to include in their ceremony: intense focus on the goal, radical collaboration, hunger to crush, and celebration of Team’s achievements (not individual’s).
They just agreed on few, simple but powerful rules. First, it had to happen at the same time every day, and with the whole Team, allowing them to communicate often. Second, the daily meeting could not last more than fifteen minutes. The idea was to keep it intense and go directly to the point. Leading to the third rule: everyone had to actively participate, no distractions, standing up to maintain focus. This is how the Daily Scrum was born.
What happened next? They suddenly increased their performance by 400%. This simple ritual allowed the development Team to keep focusing on the right stuff, detect and resolve impediments early, and give them the motivation to achieve great things.
Today, each and every Agile framework have its own version of it — whether you call it: Stand-Up Meeting, Huddle, Daily Stand-Up, Daily Meeting, Morning Roll Call, Daily Huddle Meeting, Daily Scrum, Daily Check-In, or any other name doesn’t matter — and they look pretty much the same.
Nowadays
Many Lean software development Teams have already started to include the practice in their toolbox. The format is slightly different from the one suggested by Scrum, though. The idea there is not to be people-oriented (e.g. answering the three questions), but instead, to read the board from right to left and discuss the near-the-end tasks first (flow-based) or sometimes to walk through the board and let the tasks speak (work-oriented). We’ll explore deeper the formats in use and innovative ones in the third part. Some people using Waterfall, V-model or Spiral methodologies have also started to use Huddles to improve the communication and manage the risks on a daily basis. It looks a lot more like a status report, plan execution report, or top-down information sharing, but at least it exists.
Over the years, as the need to scale from one to multiple Agile Teams, or even to a full Lean-Agile enterprise was becoming more urgent, people started to wonder how to balance Team autonomy, information sharing, synchronization needs and alignment. This is how the Scrum of Scrums was born. One of the first large-scale Scrum organization, IDX Systems (a 1996 US healthcare software company) had to deal with hundreds of developers working on dozens of differents products [Sutherland, 2001]. They faced the same challenge as every Lean-Agile organization when they want to scale-up Agile: how to find the right balance between Team autonomy and organization sustainability. They imagined an interesting approach based on a big web of Scrum Teams which everyone was part of, including the managers. They kept focus by running Daily Scrums in each Teams, Weekly Scrum of Scrums with the leaders of each Teams at cross-Team level, and Monthly Management Scrum Meetings. This concept of endless scale was then extended as the core practice of all the scaled Agile approaches, allowing information to cascade from bottom to top and decentralizing decision-making to the appropriate levels.
References
- Wacker, K. (2009). American sign language and football [Blog post]. Retrieved from http://www.lifeprint.com/asl101/topics/football-02.htm
- Amin, Z., Guajardo, J., Wisniewski, W., Bordage, G., Tekian, A., & Niederman, L. G. (2000). Morning report: Focus and methods over the past three decades. Academic Medicine, 75(10), S1-S5. Retrieved from https://journals.lww.com/academicmedicine/fulltext/2000/10001/morning_report__focus_and_methods_over_the_past.2.aspx
- Joint Commission Center for Transforming Healthcare. Hand-off communications. Retrieved from https://www.centerfortransforminghealthcare.org/improvement-topics/hand-off-communications
- Joint Commission Center for Transforming Healthcare. Hand-off communications Targeted Solutions Tool: fact sheet. Retrieved from https://www.centerfortransforminghealthcare.org/-/media/Enterprise/CTH/Documents/What-We-Offer/Hand-off-communication-TST-Fact-sheet-8-15.pdf
- Coplien, J. O., & Erickson, J. (1994). Examining the software development process. Dr Dobb’s Journal of Software, 19(11), 88–95.
- Sutherland, J., & Sutherland, J. J. (2014). Scrum: The art of doing twice the work in half the time. New York, NY: Random House. pp. 61–62, 76–81.
- VersionOne (2019). VersionOne 13th annual state of agile report (№13). Retrieved from VersionOne website: https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508
- Sutherland, J. (2001). Agile can scale: Inventing and reinventing Scrum in five companies. Cutter IT Journal, 14(12), 5–11.
