Software Teams versus Groups

What’s distinguishes a team from a group?

In the cultural sphere of my youth, basketball seemed the quintessential team game. I was a playground hoops rat who grew up tolerating ego-centric ball hogs. I’d wonder, why don’t these rubes appreciate the team game?

I dreamed of a team game, modeling and emulating the unselfish play of the 1969-70 NBA champion N.Y. Knicks.

In retrospect, my hoop dreams chums and I were a motley collection of pubescent mouth-breathers missing that magic chunk of gray matter that enables a flock of humans to behave like the symphony of a single organism (e.g., Self-Organization: Flocks, Schools & Colonies).

Compare the shooting stats of the 1969 Knicks with the 2008 NBA runner-up Lakers — a striking difference in the distribution of shots per game for the top 6 players of both clubs is evident.

1969 Knicks Shots per Game
Willis Reed 17
Walt Frazier 15
Dave Debusschere 14
Bill Bradley 13
Dick Barnett 13
Cazzie Russell 10
Mean 13.2 and Std. Deviation 2.4

2008 Lakers Shots per Game
Kobe Bryant 21
Pau Gasol 13
Andrew Bynum 10
Lamar Odom 9
Derek Fisher 8
Trevor Ariza 7
Mean 9.9 and Std. Deviation 5.2

For the Lakers, Kobe Bryant took 3 times the shots per game than 6th man, Trevor Ariza. For the Knicks, Willis Reed, took 1.7 time the shots per game than 6th man, Cazzie Russell. Which club feels like a team? Which feels like a group?  My apologies for leading the witness.

The ’69 Knicks and the ’08 Lakers, by all accounts, were wildly successful in their respective eras. Most people would probably choose to play on a team similar to the Knicks, where everyone was assured roughly the same number of shots. Is selflessness an indicator of team success?

Confession

I started this post thinking unselfishness was a defining characteristic of successful teams. I planned to compare a team player’s team, like the 1969 Knicks, with a ball hog team, like Kobe Bryant and the 2008 Lakers, but a funny thing happened:

The premise did not ring true.

Working Thesis

Most of us would rather play on an unselfish team, but unselfishness, while an attribute of a attractive team, is not an attribute that defines a successful team.

Teamwork is less concerned with democratic, unselfish distribution of tasks and skills, then with recognizing how best to combine the strengths and weaknesses of the players.


I suspect that successful teams determine – by a sometimes brutal mechanism akin to natural selection – which player should fill which role based on complementary strengths and weaknesses. These roles are not appointed, they emerge. Roles emerge as strengths and weaknesses are evaluated through trial and error. Appointed roles rarely work, but who doesn’t know the go-to-guy 3 weeks into a project?

Avoid the trappings of appointing and anointing. Try letting roles emerge.

The Greek syn-ergos is the root of the English synergy meaning working together. Synergy describes conditions where entities cooperate advantageously for a final outcome. Synergy is an over-used word that feeds the old saw

The sum of a team’s parts is more important than any individual

Groups begin the path of team transformation when each group member acknowledges and pursues a shared goal. When group members are able to subjugate personal ego in the pursuit of the most efficient path to a shared goal, they cross into the realm of team.

Teams display emergent behavior which is a collective behavior that is largely unpredicted by the behavior of individuals taken separately. Sometimes simple entities like individual players, form more complex behaviors as a collective. NBA teams assemble players based on roles like shooter, rebounder, defender, etc. They build around core players and skills that fit a style or vision with complementary players and skills.

Teams where players emerge into roles are not necessarily exclusive from the much ballyhooed cross-functional teams. On the best NBA teams, when the shooter gets hurt, other team members fill the void by taking more shots. Because you emerge as the best person to branch of your source code, doesn’t mean you are – or should be – the team’s exclusive branching dude.

I have heard the phrase self-directed teams used to describe teams that are given autonomy and take responsibility. Teams are self-directed by definition, so self-directed team is as redundant as Free Gift or Frozen Ice. Perhaps “self-direction” is merely another characteristic that distinguishes a team from a group.

Following is a working enumeration of some of the characteristics that might distinguish a team from a group:

  • Teams work toward shared goals
  • Teams have emergent roles based on the most efficient path to shared goals
  • Teams emerge as a single organism when advantageous
  • Teams have emergent behavior unpredicted by individuals
  • Team members subjugate individual ego for the sake of team efficiency
  • Teams are self-directed

10 Critical Unity Factors in Cross-Functional Teams

At the core of successful Agile software projects are cross-functional and self-organizing teams. How is the “health” of your team?


Executive coaches Emilio De Lia and Ellen Fredericks identify 10 critical unity factors in cross-functional teams in their publication From Cross Purposes to Cooperation.

Below are their 10 critical unity factors along with associated questions posed by the authors (cf. italics). Each unity factor is annotated with observations and commentary from the in-the-trenches perspective of a Agile development teams.

(1) The Customer Factor
What is the team’s relationship to its customers?

In Scrum, the Product Owner is the customer proxy. In most organizations, the “customer” is a large group with diverse interests and agendas. In successful Agile teams, team-members know and understand the customer. The iterative process of planning, prioritizing, and evaluating (e.g., retrospectives) is a rallying force and structure. Ideally, communication between customer and team is not filtered by the interpretation of a middle man (e.g., a business analyst’s interpretation of requirements).

(2) The Engagement Factor
Does the team engage its members to the level necessary for the team to succeed?

Disengagement characterizes a dysfunctional team. All members must be satisfied their talents and strengths are used. Agile teams benefit from drafting a “development manifesto” at the outset of the project that outlines what is expected of the team. Architectural choices, coding practices, and standards are decisions made by team consensus. Team-members must share ownership and accountability.

(3) The Identity Factor
How strong is the team’s identity?

A well-oiled Agile team has a common purpose, is proud of what the team stands for, and is proud of the team’s incremental accomplishments delivering a product. Agile teams are often comprised of members who initially identify with their functional organization in the larger corporate hierarchy. Over time, this identity must evolve so that it is centered about and focused on the product (e.g., The Virtual Widget Team is an identity based on a product called the Virtual Widget). Building team identity around common purpose inevitably generates engagement and passion.

(4) The Behavior Factor
Does the team exhibit constructive norms and behaviors?

In a well-oiled Agile team, team members respect and abide by agreed upon behaviors detailed in the developer manifesto. Some teams explicitly try to root out the silo-ing of knowledge by distributing tasks accordingly. The team strives for this behavior and praises themselves for demonstrating it. High-performing Agile teams will self-correct destructive behavior. For example, one team member might suggest a paired-programming session to shine a light on something going badly, rather than continuing on a solo path “off into the weeds”. Sprint retrospectives are often the best forum for evaluating, and self-correcting, destructive behaviors (e.g., gossip, technical cliques, blaming, withdrawing, or complaining).

(5) The Plan Factor
Does the team have a clearly defined plan of action that its members believe in?

Iteration planning (or Sprint planning in Scrum) typically has well-defined steps of indentifying stories, prioritizing stories, tasking stories, and generating estimates around the tasks. Many teams go the extra distance of “talking in tests”. That is, each story (or task) has a list of tests that constitute “completion” of that story (or task). When successful, good planning yields a clear plan of action.

(6) The Process Factor
How effectively does the team communicate and make decisions?

Agile teams must establish trust amongst members. Trust enables members to discuss sensitive subjects and to make controversial decisions in a way that is satisfying to the group. Team-members must be able to subjugate ego and ask for help when needed. Team-members must understand each other’s strengths and weaknesses. They must act in each other’s best interest. The decision-making process should be simple and actionable (e.g., who, what, when, and how). Consensus vote is the preferred approach to decision-making because it generates the greatest participation.

(7) The Function Factor
How are the team’s efforts integrated into the functional organization?

Some of the biggest challenges are the demands and constraints of the hierarchical organizations outside of an Agile team. Ideally, Agile teams behave like startup companies. That is, it is a flat organization where team-members wear multiple hats and responsibilities are equitably distributed. Institutional inertia and institutional controls outside of the team can often hamper team velocity. How does the team deal with these impediments and road-blocks? A ScrumMaster is often the person called upon to buffer the members from the counter-productive bureaucracy threatening the team.

(8) The Feedback Factor
How is performance evaluated and rewarded?

Agile teams have an end-of-iteration show-and-tell followed by a retrospective. This is a time where stock is taken of accomplishments, feedback is provided by the Product Owner, and the team looks back retrospectively to determine “what worked”, “what didn’t work”, and “what action items” are needed to improve.

(9) The Responsibility Factor
What level of responsibility and commitment do members of the team demonstrate?

The daily Scrum makes responsibility and commitment difficult to shirk. Scrum or stand-ups require each member publically and succinctly state what he accomplished yesterday, followed by a declaration of what he’ll accomplish today. Many teams assign story “ownership” to developers. While they might not work any tasks attached to the story, the “Story Owners” are responsible for shepherding the story to sign-off by the Product Owner.

(10) The Self-Interest Factor
Do team members see personal advantages to working on the team?

In high-performing Agile teams, individuals value the personal payoff (e.g., “I’m learning new things” or “I’m getting kudos from my teammates”). Furthermore, each member is proud of his contribution. The artifacts of personal payoff and pride in craftsmanship are easy to smoke out in the end-of-iteration show-and-tell or in the retrospective.

De Lia and Fredericks also provide a cross-functional team scorecard called TRUID. TRUID is an evaluation checklist that establishes a relative measure of how well your team is functioning as a team.

These 10 critical unity factors will help evaluate the “health” an Agile team and perhaps provide a basis for self-correction.