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.

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.