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.