Myths abound in the common beliefs on setting up teams for success.
Many of the traditional leader beliefs about teams work against the potential benefits of teams.
J. Richard Hackman was a leading expert on teams as the Professor of Social and Organizational Psychology at Harvard University. This post expands upon Hackman’s article, The Six Common Misperceptions About Teamwork 1, and outlines six key Agile leader thinking patterns for creating awesome teams.
Leader Pattern 1 – Encourage Different Perspectives
| Misperception | Reality |
|---|---|
| Harmony helps team efficiency. | Conflict and differences of opinion generate better, innovative solutions. |
Contrary to popular belief, teams work best when there are disagreements amongst the members on the best path to solve a problem. In the presence of different opinions and some constructive friction, the solution will be more innovative.
Putting It Into Agile Practice
Setting the stage to enable constructive debate is the first step to implementing this pattern in your Agile team.
When staffing your team, look for differing backgrounds across team members. Look for those that think differently. Bring members with varied skill specialties into the team. If your team is self-selecting, provide this guidance to the team in selecting its members.
Additionally, team members will not voice opposing views without safety within the team or outside of it. Hence, it is imperative that you, as an Agile leader, support a safe space for thinking differently. In other words, celebrate this behavior. When ideas don’t work out, avoid criticizing this as a waste of time. Safety is a prerequisite.
Now that your team composition is set and safety is present, you now need to support your team to debate different viewpoints.
First, encourage team members to voice different perspectives and debate on alternative paths. The team should debate the cons as well as the pros of a given solution. No question or comment is off limits. In other words, support questioning everything versus “falling in line.” As a leader, ask questions to the team to help them critically think about multiple angles to solve a problem.
Next, your team should have innovation as a driving force. In contrast, they should not be order takers. The safe environment will enable innovation. As an Agile leader, let your team know that innovation is an investment you are willing to make to ensure future delivery success. If their innovations are not successful, celebrate them trying something different. If all innovations succeed, the team is not pushing the boundaries of innovation.
Pattern 1 Conclusion
In summary, the first pattern provides an initial step in reprogramming our thinking as leaders on how to optimize Agile teams for success. A diverse team composition and a safe environment are key first steps. Then, as a leader encourage debate and innovation.
Leader Pattern 2 – Stabilize Teams
| Misperception | Reality |
|---|---|
| Rotation of team members mixes things up and keeps ideas fresh. | The longer a team stays together, the better they perform. |
The common thinking is that complacency will develop over time. In other words, we worry that team members, when together too long, will get stuck in their ways and not recognize that they need to pivot when changes in their context require it. If relationships and bonds become too tight, we fear that team members will become too tolerant of misbehavior within the team.
However, Hackman reveals that his research cannot be refuted in this area. Teams that stay together longer simply perform better. Our assumptions and existing beliefs are wrong.
Putting It Into Agile Practice
Usually, Scrum teams track their ability to deliver working software during a Sprint using Velocity. It is a fact that any change to the team membership will negatively impact a team’s Velocity.
This impact can be best explained by referring to the Team Development Model, formulated by Bruce Tuckman in 19652. Most noteworthy, this model explains that all teams go through four stages of development—Forming, Storming, Norming, and Performing. Any change to the team composition will take the team back to the Forming stage. As a result, this disruption is akin to hitting a reset button on team dynamics and team effectiveness.
Additionally, disruption on a team can occur if their domain changes even if the team stays whole. If the team switches to a new product, for instance, this will disrupt the team for a period of time. The team has to build new operating norms and learn the domain. However, gaining domain knowledge builds flexibility into the team. As a result, disruption becomes a worthwhile investment if needed in the future.
With this knowledge in hand, promoting long-lived teams with skills in multiple domains provides the best results. Long-lived teams stay with a product through its entire lifecycle. Furthermore, these teams will not end when their product ends. Rather, they will live on to build a new product. As a result, their domain knowledge will expand.
If a team needs new knowledge, allow them to organically acquire knowledge by pairing with members from another team as illustrated in Figure A. See the prior post, How a Stable Team Grows in Capability, for details on this technique and other options to avoid.
Pattern 2 Conclusion
The second pattern—Stabilize Teams—builds on the first pattern for Encouraging Different Perspectives. In short, a diverse team with different perspectives that stays together will be the strongest. By practicing this pattern, your team will be an unstoppable force.
Leader Pattern 3 – Small is Big
| Misperception | Reality |
|---|---|
| Bigger teams have more capabilities to complete the work and ensure adoption of what is built. | Small teams promote stronger team collaboration, shared understanding, and productivity. Social loafing is a common problem with large teams. |
- Is your team too large for the task at hand?
- Is your team too small for the task at hand?
Most noteworthy, the results of the study showed that the optimum number is 4.6 team members. This rounds up to 5. Also notable, Hackman was known for never allowing team sizes larger than 6 in his classes at Harvard. According to Hackman, there was a notable decline in operation when teams in his classroom grew larger than 63.
As the size of a team expands, the number of social interactions required to keep members of the team in sync grows exponentially. Notably, a study on How to Design Small Decision Making Groups4, calculates that once a team grows past 5, the number of social interactions becomes increasingly difficult to manage as shown in Figure B.
Also, this study presents 5 as a good number for decision-making. An odd number of members allow for a tiebreaker opinion.
Putting It Into Agile Practice
The Scrum Team has three roles—the Scrum Master, the Product Owner, and the Development Team. The Scrum Guide7 recommends Development Team size be between 3 and 9 members. This does not include the Scrum Master and Product Owner. Using the data on small team sizes, the optimal Development Team size is at the lower end of the range—3. Adding in the Scrum Master and Product Owner will arrive at the ideal team size of 5.
However, for your team to have all the skills necessary to develop your product, the team may need additional Development Team members with the appropriate skill sets, requiring the team to migrate to the higher end of the Scrum guideline. As the team members learn from each other over time and become more fungible, the original skill gap that required additional team members will no longer exist. The team can then consider splitting into two teams.
However, splitting the team must be weighed against Pattern 2—Stabilize Teams. If a team is on the larger end of the scrum team size range, splitting will add significant benefits to the team’s collaboration, shared understanding, productivity, and ability to learn from each other. Furthermore, this gain will likely outweigh the temporary destabilizing impact of splitting the team into two.
As always, you should let the team decide when and how to split. Usually, the team will naturally self-organize into smaller sub-teams within a larger Development Team size. Once the sub-teams are norming or performing, formally splitting the two sub-teams becomes an easier and more favorable option.
Pattern 3 Conclusion
The third pattern—Small is Big—goes against common wisdom that adding members to a team will increase a team’s productivity. A small team will find it easier to stay on the same page, collaborate, finish work, and learn from each other.
Leader Pattern 4 – Enable Face-to-Face Interaction
| Misperception | Reality |
|---|---|
| Face-to-face communication is no longer necessary in the age of digital communication. | Remote communication and collaboration is low bandwidth and puts teams at a significant disadvantage. |
- Build stronger relationships
- Experience higher quality communication and collaboration
- Accelerate team learning
Additionally, non-verbal communication is often more important than what you say. When teams are remote, picking up on non-verbal cues is extremely difficult even with the best technology available today.
Putting It Into Agile Practice
The Agile Manifesto highlights this pattern clearly in the following principle:
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
In his book Agile Software Development8, Alistair Cockburn models different modes of communication and their effectiveness. The communication quality of different communication modes is depicted in Figure A.
Face-to-face interaction is more effective than any other means of communication. This is largely due to non-verbal communication cues. Also, when face-to-face at a whiteboard, team members rapidly address interpretation gaps and converge to a shared understanding.
Co-location and Remote Teams
Co-location of team members and teams in a multi-team product will enable the right environment conducive to face-to-face interaction. If you have a choice, don’t have geographically remote team members or remote teams.
Interestingly, geographic distance is not the only way to hinder the effectiveness of team communication. Alistair Cockburn found that if the team’s members sit apart futher than a bus length, communication drops off rapidly5. Often, team members will not get up to have a face-to-face interaction if further apart than a bus. Therefore, being on the same floor or the same building does not count as co-location. If team members are further apart than a bus, they are not co-located.
If you have no choice but to have a Scrum team’s members separated geographically, there is something you can do. Bring team members together at the beginning and at several key points throughout the life of the team. As a result, your teams will build better relationships and will be more effective when working remote.
When you have a remote team, make it whole. In other words, all team members should be co-located in the remote location. For a Scrum team, this means the Scrum Master, Product Owner, and Development Team members should be co-located.
Additionally, distributed teams can also pose communication barriers. Distributed teams occur when a product has more than one team, but the teams are not co-located. In this scenario, bring the distributed teams together at their inception and at as many key points as possible throughout the life of the teams.
Pattern 4 Conclusion
The fourth pattern—Encourage Face-to-Face Interaction—shows that even with today’s technological advances, face-to-face interaction retains its top spot as the highest bandwidth form of communication and collaboration. A co-located team will also find it easier to build relationships and learn from each other.
Leader Pattern 5 – Enable Self-Organization
| Misperception | Reality |
|---|---|
| The leader makes the team. | Hands-on leaders make a difference, but the optimal impact of a leader is achieved by fostering competent self-organization, launching the team effectively, and coaching in real-time. |
Notably, Hackman states that the leader’s ability to enable the team to competently self-organize accounts for 60% of the variability in the success of the team. Enabling the team to manage themselves is the most powerful service a leader can provide to a team.
The second most effective thing a leader can do is effectively launch the team. This accounts for 30% of the variability in the success of the team.
Finally, the leader’s coaching of the team is only accountable for 10% of the team’s success trajectory1.
A leader is key to team success but not in the way we typically believe.
Putting It Into Agile Practice
The following Agile principles are applicable to this pattern from the Agile Manifesto:
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The best architectures, requirements, and designs
emerge from self-organizing teams.
How we go about achieving this comes down to serving the team, building up team capabilities, and instituting a solid team launch and onboarding process.
Serve the Team Instead of Managing Them
Go see your team at the place where they work. In other words, be with your team and see their impediments firsthand. This is crucial for serving your team in the right way. Toyota referred to something called Gemba—“the actual place” of work, and encouraged managers to have Gemba Walks9 to see problems firsthand.
Gemba walks are a method of observation and should not be a problem-solving activity or taken as an opportunity to point out problems. This technique is a key means of empathizing with your teams and learning how you can serve them by improving the system within which they work.
Instead of managing your teams within the sprint, let them self-organize around what they can control. If you can switch your focus as a leader to helping the team remove waste that they cannot remove themselves, you will serve your team best. See the prior post, How to Shift Gears to Become an Agile Leader, for an in-depth discussion on this topic.
Build Team Capabilities
As an Agile leader, it is critical that you switch your mindset from managing your team to leading your team. As a result, by letting go, trusting your team, and allowing them to take control, they will self-organize if they have the capability to do so. This is a critical point—a team can self-organize only if they have the needed behaviors and skills. Your job as a leader is to support the acquisition of these behaviors and skills.
If your team needs to build capabilities to become self-organizing, you can support this as an Agile leader. Refer to the following posts for in-depth discussions on this topic:
- Overcoming the Fear of the Incapable Team – Read for guidance on how you can coach the team to learn new skills
- How a Stable Team Grows in Capability – Read to find out how your team can gain new skills organically without changing team composition.
- Can Coaching and Self-organizing Behavior Co-exist – Read to discover how your Agile coach can build new Agile beliefs in your team and help them to become self-organizing.
Launch and Onboard for Success
Launching your team for success is supported by the four prior patterns for Awesome Teams—Encourage Different Perspectives, Stabilize Teams, Small is Big, and Encourage Face-to-Face Interaction. Additionally, a focus on onboarding is key for launching your team. A solid sprint 0 for your team will include the following readiness activities:
- Agile framework, business domain, and technical training
- Product visioning, road mapping, and release planning to seed the initial backlog
- Team relationship building
- Formation of team working agreements, the definition of ready, and the definition of done
- Team room configuration
- Collaboration on the product technology architecture conceptual design and coding standards
- Engineering practice tooling and automation preparedness
- Environment setup and configuration
While we prefer stable teams, if it becomes necessary to bring in a new team member, many of these onboarding activities above should be repeated for any team member additions.
Pattern 5 Conclusion
The fifth pattern—Enable Self-Organization—shows that managers, through leadership, can enable self-organization to emerge within a team. Through direct observation of team needs, the leader can remove problems that impede their teams and increase team control and ownership over what they deliver. In order to enable self-organization, a team must have skills and capabilities, and a leader must support the team in growing these capabilities. Finally, ensuring adequate onboarding of a new team or new team members is a key role of the leader and instrumental to team success.
Leader Pattern 6 – Serve the Team
| Misperception | Reality |
|---|---|
| The benefits of teamwork happen automatically. Just put a group of talented individuals together, and sit back and watch the magic happen. | Leaders of teams must define why the team exists and what they need to accomplish while serving and supporting them in achieving that goal. |
Simply forming a team is not enough. Expecting them to self-organize without any guidance on why they exist and what they are trying to accomplish will likely lead to chaos and misguided actions. As a leader, it is crucial that you guide your teams on the right path.
Simon Sinek has an excellent book, Start with Why – How Great Leaders Inspire Everyone to Take Action6. Most noteworthy, the book outlines the criticality of defining why before even thinking about how you build it and what you build. To illustrate, he uses the Golden Circle as shown in Figure C.
In summary, once you have a compelling why, the team will self-organize around the how and the what.
Putting It Into Agile Practice
First, provide clear direction to your team on why they exist. Work with them to define their purpose and the vision they are striving to achieve. Additionally, formulate a common understanding of why it matters to your customers and your business.
Second, determine what your team should focus on to achieve their why. Define the objectives in achieving the vision. Work with the team to clearly define their responsibilities and what capabilities they provide to solve the problem. Encourage a continuous improvement focus to iterate and innovate on what the team is building to achieve their why.
Rather than hand your team a definition of their why and what, involve them in the creation of it. Accordingly, connect your teams directly with their users to gain a fundamental understanding of user workflow and user need. As a result, this will energize creativity in your team, and the team will bring their ideas to the table. The wisdom of the team will craft a better solution than you could possibly form on your own. Most importantly, since you have collaborated with them to converge on a solution, they will have ownership of the solution.
Third, remember that How is squarely in the team’s court. With a shared understanding of the Why and the What, your team will self-organize around How to build the solution if they have the capabilities to do so. Often, your team will need new skills to self-organize around the How. For instance, perhaps they need to learn a new technology, gain domain knowledge, or learn Agile-related behaviors. As a leader, you can provide them the appropriate training or coaching and cultivate a culture of growth. See the prior posts for more guidance on this.
- How a Stable Team Grows in Capability
- Can Coaching and Self-organizing Behavior Co-exist
- Overcoming the Fear of the Incapable Team
Finally, as in Pattern 5—Enable Self-Organization—if you can switch your focus to helping the team remove waste that they cannot remove themselves, you will serve your team well. See the prior post, How to Shift Gears to Become an Agile Leader, for an in-depth discussion on this topic.
Pattern 6 Conclusion
The sixth pattern—Serve the Team—demonstrates how you can collaborate with your team to set their purpose. Connecting them directly with their users will ignite innovation and will bring forth the power of the team in collaborating and converging on a direction. Also, you should promote and support a culture of growth to allow your team to gain new capabilities. Lastly, shifting your focus to removing waste that they cannot remove serves the team and sets them up for success.
Conclusion
The six patterns presented in this post reprogram our thinking as leaders on how to optimize Agile teams for success. By practicing these patterns, we will move towards true, effective teamwork and build awesome Agile teams.
References
- The Six Common Misperceptions About Teamwork, Robert J. Hackman, June 7, 2011
- Developmental Sequence in Small Groups, Psychological Bulletin 63, B W Tuckman (1965)
- The Power of Number 4.6, Fortune Magazine, June 12, 2006
- How to Design Small Decision Making Groups, Intuitor.com
- Agile Software Development as a Co-operative Game, 2nd Edition, Alistair Cockburn, Page 23
- Start with Why – How Great Leaders Inspire Everyone to Take Action, Simon Sinek, October 29, 2009
- The Scrum Guide – The Definitive Guide to Scrum: The Rules of the Game, Ken Schwaber and Jeff Sutherland, November 2017
- Agile Software Development, Alistair Cockburn, 2001
- The Many Sides of a Gemba Walk, Russel Lindquist, isixsigma.com
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.