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

MVP of your Agile Team

I engaged four Agile and Scrum discussion groups with the question:

Which person is more valuable to an Agile team?

One with SUPERIOR KNOWLEDGE of software systems and architecture
— or —
One with AVERAGE KNOWLEDGE capable of admitting what he doesn’t know

And, who would you rather work with?

Many in the Scrum Practitioners Group and Agile Alliance Group misunderstood the gist of my question. Probably because the question is “Bobtuse”. Among the Scrum crowd, it sparked a somewhat embarrassing thread about Product Owner versus ScrumMaster. Not my intent. I blamed myself for misleading them, then offered further explanation that I’m entertaining a thesis that the sublimation of ego is a crucial ingredient to team success.

I coined the aphorism

“Humility is the WD-40 of teamwork

I did get many thoughtful responses. Management consultant Steve McGee fed me:

“..a passion for knowing the truth, contrasted to a passion for being right…”

from something he noticed while reading about gender communication differences. He said,

“… men are stereotyped as always competing to be right. I was offended by that, and after thinking about it, it seemed this distinction had been missed. In both cases there will likely be an argument or at least debate. But the goals and therefore the results will be totally different.

Steve agreed that to get an honest evaluation and transparency, team members need to subjugate their egos. He went on to say,

“If a person is willing to trade certainty (accept ambiguity) so they will not miss any potential information, he or she will get closer to understanding what’s really going on and can respond more effectively.”

Thanks Steve.

My Agile mentor, David Hussman said,

I feed on environments where people are proud to say they don’t know. Some of the smartest people I know, know when to say they don’t know, and when to shut up and listen.

Thanks David.

Regarding who he’d like to work with, Agile coach Paul Ellarby said,

“…it all depends upon their personality. I have worked with individuals who freely admit they are “not experts”, yet try to dominate all discussions around their area of responsibility. Similarly, I have worked with folks who clearly are highly valuable experts, yet listen carefully to the teams dialog, and respond in clear, concise, and respectful tones.”

Paul also reminded me of the aphorism “Two ears, one mouth – use them in proportion…”.

Thanks Paul.

Was it Socrates or Epictetus who said

we have two ears and one mouth so we listen twice as much as we speak”?

5 Characteristics of Effective Teams

One of my favorite engineering professors is Karl Smith. Karl Smith, Professor of Civil Engineering at the University of Minnesota, has researched and written extensively about the “engineering method” and teamwork. In the book Teamwork and Project Management, Karl summarizes what he and colleagues recognize as 5 characteristics of effective teams:

Positive Interdependence
“The team focuses on a common goal or single product”

Individual and Group Accountability
“Each person takes responsibility for both her or his own work and the overall work of the team”

Promotive Interaction
“The members do real work, usually face to face”

Teamwork Skills
“Each member has the skills for and practices effective communication (especially careful listening), decision making, problem solving, conflict management, and leadership”

Group Processing
“The team periodically reflects on how well the team is working, celebrates the things that are going well, and corrects the things that aren’t”

These characteristics were observed and derived by Karl and his colleagues from many years of working with civil engineering groups and other teams of engineers comprised of students and practitioners. Those acquainted with Scrum, or Agile methods, should recognize these characteristics from their experiences with successful software teams.

Scrum, in particular, has nomenclature that jibes with these characteristics (e.g., Product Owner, Daily Scrum, Scrum Pit, and Sprint Retrospective).

Positive Interdependence is fulfilled by a Scrum team that designates a “Product Owner”. The Product Owner drives priorities and keeps the team focused on the Product. In Scrum, work tasks are product-driven.

Individual and Group Accountability is fulfilled by a Scrum’s emphasis on having each member take tasks to work on, then reporting daily progress to the team during the “Daily Scrum”. Some Scrum teams have “Story Owners” which give individual members the additional responsibility of making sure the team progresses toward completion of Story tasks and then shepherds the Story through Product Owner approval (“Story Sign-Off”).

Promotive Interaction jibes with the “Scrum Pit”. The Scrum Pit is a physical location where team members work in close proximity. I have witnessed improvement in Scrum Pit interaction if team members are turned to face each other, rather than with their backs to each other. I have also found that paired-programming sessions enhance cross-functional learning and limit knowledge silo-ing.

Teamwork Skills are not necessarily tools that every team member has at the outset of a project, but Scrum encourages the development of these skills by structuring the project for group decisions and by creating a daily routine of communication in the “Daily Scrum”.

Group Processing is fulfilled by Scrum’s “Sprint Retrospective” where the team examines the previous Sprint to discuss “what went right?” and “what went wrong?”, and to agree upon “action items” for improvement. Typically Scrum teams will have a retrospective meeting every 2 weeks or every month depending on the length of their Sprints.