One of the most iconic television shows of the 1980s (83 – 87) was the A-Team. In the A-Team, the four team members combined their talents to right wrongs and conquer evil. In a precursor to Agile, the team was cross functional and in the context of the larger world, self-organizing. While the A-Team reflects Hollywood’s perception of a team, the lesson shouldn’t be lost that for most software development or maintenance efforts teams are necessary to get things done. If teams are a necessity, then it is important to understand the attributes of an effective team. For any specific effort, the best team (or teams) is a function of team dynamics, capabilities and the right number of bodies.
Team dynamics are an expression of how the team interacts with each other and those outside the team. A recent installment of Google’s “The Water Cooler” blog reported on a study done by Google on what makes a team effective at Google. They found five critical factors:
- Psychological safety. Risks can be taken without causing insecurity or embarrassment.
- Dependability. Team members can count on each other (people say what they will do and do what they say).
- Structure and Clarity. The goals, roles, and execution plans are clear (and shared).
- The Meaning of Work. The work is important to the team members.
- The Impact of Work. The team believes that their work matters.
What team members believe and how they interact turned out to be the most important factors that lead to effective teams in the Google universe. Interestingly, a New York Times article (Sunday, May 29th, 2016, Sunday Review Section p1, 4-5) written by Alain de Botton, titled “Why You Will Marry the Wrong Person” makes a similar argument about couples. In the article, he stated:
The person who is best suited to us is not the person who shares our every taste (he or she doesn’t exist), but the person who can negotiate differences in taste intelligently — the person who is good at disagreement.
The same focus on dynamics reinforces Google’s findings that the right dynamics unlock a team’s potential. Note: This another VERY strong argument not to mess with the structure of teams that work well, if at all possible.
Capabilities are abilities individuals have or can acquire to solve problems presented to the team. Capabilities include the knowledge of the business problem, application, and technical skills in applying tools, languages, and frameworks. One capability often not readily considered is knowledge of the lead time (Knowledge Options) to learn a new skill or techniques that might be needed to address a problem. Knowledge options are where you know just enough about a subject to know how to apply the subject and how long it will take to get up to speed on the topic when needed. Understanding both current skills and the collection of a team’s knowledge options dramatically increases the breadth of technical and business problems any specific team can address.
Individual Agile teams are typically constrained to five to nine bodies. More than nine tends to cause communication problems, and in teams of less than five, it is difficult for the team to have the capabilities needed to address most sizable software problems. Large Agile efforts typically require multiple teams (scaling Agile). Business need and budget help to determine how many people (and therefore teams) will be needed.
Part of starting an Agile effort is determining who will be involved, what their capabilities are or can be and finally a rough count of the teams that will be needed. Even if the goal of the effort does not change, the path towards that goal will evolve, which means that many of the factors originally forecast (including scope, budget, people, and capabilities needed to deliver) will also evolve. However, without some forecast of the people or teams needed it is difficult to get any effort started Agile.