How a Huddle Can Serve Team Self-Organization

15 min readJan 30, 2020

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 main purpose of the Huddle (also known as Daily Scrum, or Daily Stand-Up Meeting) is to foster a Team’s ability to self-organize. However, not every Huddle I observed as a coach smells like Team self-organization… Far from it! I have learned from years of experience and readings that a good Huddle, one which can serve Team self-organization, has to be composed of four key aspects: synchronization, collaboration, coordination and motivation; all this supported by servant leadership.

For example, during the famous Daily Scrum from the Scrum Guide [Schwaber et al., 2017], Team members are encouraged to answer to three questions, inducing three separate phases for each individual:

“What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?”

While this format may be controversial, I consider these three questions as an invitation for the Team to synchronize (question 1), collaborate (question 3) and coordinate (question 2). Motivation does not formally get its own question, but should be considered during the whole event, and/or as the opening and closing (remember, the first Scrum Team took example from the haka dance).

Team synchronization

In the field [Stray et al., 2012], Teams tend to spend more time on question 1 (53%) than on others (respectively 25% and 22%). Redundancy of the information plays a key role in a system’s ability to self-organize [Heylighen, 2002]. People have to share and gather enough knowledge to be able to act based on what have been learned. This empirical process is what distinguishes complex adaptive systems from others. As the Team discovers the work to do, it progressively increases the overall group competency through real-world experience. The depth of the topics at hand is explored step by step, as well as their width. Team members may have different fields of expertise (I or T-shaped profiles) [DaVanzo, 2012], they nevertheless extend their capabilities to eventually tend to a E-shaped skills profile. By confronting their newly acquired knowledge with others’, they are able to get an idea of what the big picture looks like, and react accordingly. Decisions are based on facts rather than intuition or dogma. Commitments are more realistic as they take into account the unstable nature of the future. Individuals are subject to a certain level of peer pressure from their teammates, ensuring everyone is contributing to the project equally. Informal commitments are made and individuals are held accountable by their peers. Team predictability is increased, making it trustworthy for the stakeholders.

The Huddle is, by nature, an information-sharing meeting. People inside and outside of the Team just have to reach out and grab the knowledge they need. May that be project knowledge (timelines, progress, plans), product knowledge (requirements, designs) or process knowledge (coding techniques, teamwork) [Ebert et al., 2008]. During the meeting, discussions are the obvious form of knowledge. But they are not the only ones, artifacts (such as requirements, backlog, or user stories), which are a representation of the knowledge, coupled with vizualisation (such as boards, burndown charts) contain a lot of key information [Andriyani, 2017] that can be seen at a glance and support the Huddle execution.

The need for status meetings is reduced as anyone can come and observe. The Team members transparently share information without restraint to other Team members. Observers do not disrupt the ritual nor participate unless the Team decides otherwise. Additional information can be shared after the meeting if needed. What is said or shown during these meetings is obviously important but a wise observer can detect many things just by paying attention to the way people communicate. Making information transparent − meaning accessible to and understandable by anyone − is a Team priority. This is the foundation upon which inspection entirely lies. And what is synchronization if not an inspection of what the Team has done and what knowledge it has gained so far? The time slot needs to be clearly communicated to stakeholders. Making it easy for them to just jump in as needed.

“Cadence and synchronization limit the accumulation of variance.” [Reinertsen, 2009]

A Huddle is a synchronization checkpoint that can be used to detect variations or flaws in the plan and quickly react. Using charts to visualize Team metrics can help identify risks early and mitigate them. Starting there, a reverse information cascade (from the bottom to upper enterprise layers) allows the entire organization to move extremely fast and align everyone as necessary. For example, in a multiple Teams environment, risks of late dependency resolution can be detected as the first signs appear, and monitored closely. An action plan can be developed early to address the issue at different levels of the organization instead of having to wait until a later checkpoint. Progress towards business objectives can be reviewed.

The consistency in the frequency of the event can help reducing communication issues, thereby acting as a heartbeat for both the Team and the organization. A daily frequency not only helps handling variations, but it also affects motivation. Synchronization is about sharing newly acquired knowledge (including what we learned from failures), but that is not all… Successes and achievements are highlighted and celebrated. Sometimes, just saying “thank you for your help” is enough. Frequent celebrations reinforce Team’s cohesion and identity, boost self-esteem, and encourage individual engagement.

Team collaboration

Collaboration is “the act of working together with other people or organizations to create or achieve something.” [Cambridge Business English Dictionary, 2019]

Depending on the organization and its maturity, a Team can possess the authority to manage — i.e. make decisions in — different areas of its activities. Hackman's works on organizational behavior led to a categorization of four incremental Team's authority levels [Hackman, 2002] :

A manager-led Team only possesses the authority to execute the tasks managers give to them;
A self-managing Team also monitors and manages work process and progress. Managers give them their tasks and they can decide how to organize the activities amongst its members and adapt their processes to better fit their objectives;
A self-designing Team have full authority on their tasks and the power to decide how the Team is designed, their working norms, and tools needed. Managers sets the direction and the Team organizes to achieve it; and,
A self-governing Team is responsible for its own direction, design, organizational context, progress, process and execution.

Decision-making is a key aspect of Team collaboration and self-organization. According to the Standish Group, a low decision latency is the primary factor of project success [Johnson, 2018]. They also suggest organizations to spend a whole quarter of their improvement budget on reducing this decision latency. Decentralizing decision-making to empower Teams should be a priority for most organizations. Traditional organizations tend to centralize every decision regardless of time criticity and the level of information people (usually managers) have when making the decision. In his book The Scrum Fieldbook, J.J. Sutherland [2019] tells this story about how two engineers started to search for survivors and cleaning debris after the World Trade Center attack in September, 11 of 2001 without asking permission. They had the right knowledge, they knew the building specifications and they knew construction people, that was enough to start digging. The key to this extremely chaotic situation was to act quickly, and that’s what they did. In order to coordinate the actions of three thousand people, they put in place a twice-daily meeting to make fast decisions and take action. Less than a year after, the place was cleaned up.

The ultimate goal is not to decentralize everything but just enough to ensure responsiveness, i.e. “taking the right action quickly in response to opportunities and threats.” [Vantrappen et al., 2017] Time-critical or frequent decisions require local information. Information that only a few people (often at the bottom of organizations, people who actually do the work) have. Tools like the delegation poker [Appelo, 2010] can be used to define and expose the allocation of responsibilities between the manager(s) and the Team. Visualisation reduces ambiguity on who is entitled to make a specific decision. The other advantage of this kind of tool is to make everyone understand how to progressively tend towards decentralization, as trust is built up.

As a system composed of people from various experiences, knowledge and personnalities, a Team creates its own political system to enable efficient self-organization. According to Ralph van Roosmalen [2019], there are five different approaches that can describe how a Team make decisions:

Aristocracy: One Teammate makes the decision. E.g., when a compliance rule needs to be put in place in a Team in order for the organization to stay reliable;
Sociocracy: One or more Teammates consult other and then make the decision. E.g., when a Product Owner facilitates a discussion between the Team and the stakeholders and then arbitrates on what will be developed;
Democracy: The majority of the Team agrees on the decision. E.g., when a Team dot-votes on the next improvement items;
Unanimity: The whole Team agrees on the decision. E.g., when a new Team member is hired; and,
Randomness: Any decision is valid. E.g., when several options seem to fit, a Team can decide to roll a die and just try one of them.

Understanding the boundaries within which a Team can operate helps in building a collective ownership. The Team owns its work functions to a certain level, i.e. it possesses the required autonomy to act on it, and is held accountable for doing it. Note that I do not talk about specific responsibilities for Team members, the Team as a whole is held accountable. This is a sine qua non condition to empower the Team and foster Team spirit.

However, collective ownership supposes that the Team has all the skills needed to perform its tasks. In other words, to truly “own” their governance (or lower levels), the Team must prove it “can” govern itself. Hard skills on task execution are obviously needed and can easily be learned by using eXtreme Programming practices such as Pair Programming [Beck, 2000]. But nowadays, especially thanks to the adoption of Agile, there is an increased emphasis on soft skills. Those help people to better communicate with others and work together. Empathy, adaptability, optimism, common sense, negotiation, problem-solving, etc. All these are things which will greatly help the Team when facing the problems of daily life. They foster and enhance collaboration by allowing the Team to consider all perspectives of a problem, gauge possible root causes, think “out of the box” and find creative solutions. Or even sometimes, just re-adjust communication style to unlock endless possibilities. For some people, these soft skills are innate. Others need coaching and facilitation, they need to work them out in a safe environment. The Huddle is a good place to observe and practice.

Collaboration implies there is something to achieve. Lean and Agile organizations always aim to focus on delivering value to customers and organization with the shortest sustainable lead time. Teams can use spontaneous, event-driven, or daily Huddles to keep focusing on the right stuff and remove obstacles that arise on their way. They also don’t have to isolate themselves from the rest of the organization. They can move, help others, go and see how others do, etc. The Scrum Guide does not contain any information on whether the Teams should solve problems during the meeting or after. A study [Stray et al., 2016] shows that Teams find it very useful to do it during the meeting. People think collectively to find a solution (collaborate) given the known information and the short time available. This promotes quick decision-making but could lead not to sufficiently consider the options. Depending on the impact of an issue, a Team may want to take time to step back a little and fix it once and for all. In any case, a good balance must be found between the effort spent on gathering data, analyzing it and act, and the relevance of the solution. More time spent doesn’t necessarily lead to better outcomes.

Whatever the subject of the collaboration is, a Team should never forget its iteration goals. During the synchronization phase, new knowledge could have been shared which completely challenge the plan for the iteration. The iteration goals will then help the Team focus on what is important (i.e. the value), and maybe change the way to achieve it. Inspecting progress towards these objectives also gives the Team a sense of whether the plan needs to be adjusted or not.

Team coordination

During a collaboration phase, the Team may have identified a set of activities to perform to achieve their purpose. The coordination phase is when they organize those different activities so that they work together effectively. In other words, it’s a planning phase. This process taking place during a Huddle, it fits into a bigger Agile planning model which highlights five distinct levels of planning [Smits, 2006] :

Product vision: a broad picture that depicts the future state of the product. It is sometimes referred to as a postcard from the future.
Product roadmap: a high-level representation of the road towards the final product (of course this road will change). This is a big picture of the sequencing of the work through the whole organization with more detail or near-term than long-term. Themes, Epics or Objectives are often used at this level.
Release plan: the advent of the DevOps mindset changed the meaning of this level. A release, depending on the context could be a major new version of an application, a set of features that will be activated at a specific date, or just a timebox of a couple of months horizon (SAFe calls it a Program Increment). Anyway, the idea is to have a plan that focuses on risks and dependencies between multiple Teams and giving a sense of what customers can expect out of this release. Features and User Stories are often used at this level.
Iteration plan: a detailed plan of what will be achieved by the Agile Team during the iteration. Iteration goals are part of this plan and the Team commits to them. User Stories and tasks are often used at this level.
Daily plan: the most detailed plan of the model. Based on its progress towards the iteration goals, the Team coordinates to plan daily activities. User Stories are updated, discussed and assigned as well as risks and impediments and the Team discusses the likeliness of achieving its iteration goals. The daily plan is then a grounded tactical plan of what Team members will do to achieve the goals. It is an opportunity to both focus on Team activities and connect with the other Teams to get dependencies resolved, risks mitigated and impediments removed.

Each of these levels implies a certain level of commitment. The whole organization commits to the customers that they will do their best to achieve the product vision and the product roadmap. The Teams commit to the customer they will do their best to achieve release and iterations goals. And Team members commit to their peers to do their best to achieve what they said they would do. But the commitment is composed of another part. Everyone — customers, organization, Teams — commits to immediately raise a red flag if there is a risk that prevents the proper execution of the plan. May that be an organizational impediment, unexpected event, change in market context or priorities that questions the plan, etc. Once everyone agreed to those two-part commitments, they are held accountable. This notion is fundamental for a Team to become highly efficient and productive [Lencioni, 2002]. Commitment, accountability and attention to results is what makes Team members reliable and what builds trust between the Team and the outside world.

Synchronization is the easy part. Anyone is able to report status and share knowledge. Collaboration is harder but can easily be facilitated. But coordination is where self-organization can really be observed. The way they divide their labor can reveal many things about a Team’s ability to self-organize. Is there a self-appointed leader that decide for others? Does everyone have an even vote? Are they able to commit to others? To communicate their commitments to stakeholders? To optimize the system and avoid bottlenecks? To connect their work to the greater whole? To see the big organization plan and understand how their work impacts it? As a coach, I love attending to Teams’ Huddles because I can learn a lot about them, quickly assess their “health” and get a first sense of where I should focus my efforts first.

Team motivation

Team motivation has been deeply rooted in the Huddle since the beginning. Remember the first Scrum Team with the video of haka dance? Honestly, how many Teams have you seen that possess this anger to win? Just a few, on my side… When using a three-question format, there is no question about the motivation. Still, this aspect should not be neglected. It can be difficult to dedicate a whole phase of the Huddle to it. Rather, small things can be disseminated through the event. Taking care of the opening helps to immediately engage people to the discussion and give them the will to eliminate the barriers facing them. A good closing provides a similar effect to the work they have to do.

Synchronization, collaboration and coordination could all be classified as “Team empowerment”. Motivation, however, is more about “energizing people”. Providing room for self-organization unlocks itself the intrinsic motivation of people. According to Jurgen Appelo [2010], intrinsic motivation is “people’s innate desires to do well and to have an eagerness for self-control and self-direction in accomplishing objectives. Successful intrinsic motivation is the result of the fulfillment of basic desires.” He lists ten “moving motivators” which can influence people’s motivation in different manners and which should be kept in mind during Huddle:

Curiosity: I have plenty of things to investigate and to think about.
Honor: I feel proud that my personal values are reflected in how I work.
Acceptance: The people around me approve of what I do and who I am.
Mastery: My work challenges my competence but it is still within my abilities.
Power: There’s enough room for me to influence what happens around me.
Freedom: I am independent of others with my work and my responsibilities.
Relatedness: I have good social contacts with the people in my work.
Order: There are enough rules and policies for a stable environment.
Goal: My purpose in life is reflected in the work that I do.
Status: My position is good, and recognized by the people who work with me.

Team identity can be used as an inspiration to convert a banal meeting into a real tribal ritual. Reinforcing Team unity and sense of belonging with occasions to gather, have fun, share experiences, while working to achieve something bigger is a great reward. I don’t say everyday will be magical and unicorns will visit us and spread joy powder over the open space, but just knowing we are not alone and that we will find a solution together and succeed as a Team is a feeling that is worth it.

Take a moment to think about the cost of a Huddle. 86% of Agile Teams [VersionOne, 2019] interrupting their work everyday for 15 minutes or so, not to mention the time after to get their thoughts back together before getting back to work… So why is this practice so badly implemented? Wouldn’t it merit more attention? Feel free to share your thoughts and comment. Thanks for reading!

References

Schwaber, K., & Sutherland, J. (2017). The Scrum guide (p. 12).
Stray, V., Moe, N. B., & Aurum, A. (2012). Proceedings of the 38th euromicro conference on software engineering and advanced applications (SEAA). IEEE, pp. 274–281. doi:10.1109/SEAA.2012.16
Heylighen, F. (2002). The science of self-organization and adaptivity. Knowledge management, organizational intelligence and learning, and complexity, 3, pp. 4–15.
DaVanzo, S. (2012, July 26). Business trend: “E-shaped” people, not “T-shaped” [Blog post]. Retrieved January 11, 2019 from https://culturecartography.wordpress.com/2012/07/26/business-trend-e-shaped-people-not-t-shaped/
Ebert, C., & De Man, J. (2008). Effectively utilizing project, product and process knowledge. Information and Software Technology, 50(6), pp. 579–594. doi: 10.1016/j.infsof.2007.06.007
Andriyani, Y. (2017). Knowledge Management and Reflective Practice in Daily Stand-Up and Retrospective Meetings. In XP 2017: Agile Processes in Software Engineering and Extreme Programming. Business Information Processing, 283, pp. 285–291. doi: 10.1007/978–3–319–57633–6_21
Reinertsen, D. G. (2009). The Principles of Product Development Flow. Redondo Beach, CA: Celeritas Publishing.
Collaboration. (n.d.). Cambridge Business English Dictionary. Retrieved January 16, 2019 from https://dictionary.cambridge.org/dictionary/english/collaboration
The Authority Matrix: Four levels of Team Self-Management. Reprinted from Leading teams: Setting the stage for great performances (p.52), by J. R. Hackman, 2002, Brighton, MA: Harvard Business Review Press. Copyright 1986 by the American Psychological Association. Adapted with permission.
Johnson, J. (2018). Decision latency theory: It’s all about the interval (CHAOS Report Series).
Sutherland, J. J. (2019). “Chaos. Uncertainty. Action.” In The Scrum Fieldbook: A master class on accelerating performance, getting results, and defining the future. New York, NY: Currency.
Vantrappen, H., & Wirtz, F. (2017). When to decentralize decision-making, and when not to. Harvard Business Review. Retrieved January 2, 2020 from https://hbr.org/2017/12/when-to-decentralize-decision-making-and-when-not-to
van Roosmalen, R. (2019). How do teams make decisions? Retrieved January 2, 2020 from https://agilestrides.com/blog/how-do-teams-make-decisions/
Appelo, J. (2010). Management 3.0: Leading agile developers, developing agile leaders. Boston, MA: Addison-Wesley Professional.
Beck, K. (2000). Extreme programming explained: Embrace change. Boston, MA: Addison-Wesley.
Soft Skills. (n.d.). Cambridge Business English Dictionary. Retrieved January 17, 2019 from https://dictionary.cambridge.org/dictionary/english/soft-skills
Stray, V., Sjøberg, D. I. K., & Dybå, T. (2016). The daily standup meeting: a grounded theory study. Journal of Systems and Software, 114(April), pp. 101–124. doi:10.1016/j.jss.2016.01.004
Coordination. (n.d.). Cambridge Business English Dictionary. Retrieved January 16, 2019 from https://dictionary.cambridge.org/dictionary/english/coordination
Smits, H. (2006). Five levels of agile planning: From enterprise product vision to team stand-up [White paper]
Scaled Agile, Inc. (2018). Program Increment. Retrieved January 25, 2019 from https://www.scaledagileframework.com/program-increment/
Planning in large scale agile projects. Reprinted from Five levels of agile planning: From enterprise product vision to team stand-up by H. Smits, 2006.
Lencioni, P. (2002). The five dysfunctions of a team: A leadership fable. San Francisco, CA: Jossey-Bass.
VersionOne (2019). VersionOne 13th annual state of agile report (№13).