Hypothesis 1: Expert Teams = Agile Teams

by Vince Kellen, Senior Consultant

The following is from a chapter in the book The Cambridge Handbook of Expertise and Expert Performance, which I have read and highly recommend. Meant for those with an academic research bent, the book brings together a lot of research regarding what makes for experts. Most of the book is dedicated to understanding individual expert performance from a psychological perspective, with several chapters focusing on separate intellectual and physical disciplines. These chapters alone contain several nuggets of empirical insight. However, in one chapter in the book, five authors (Eduardo Salas, Michael Rosen, Shawn Burke, Gerald Goodwin and Stephen Fiore) discuss what has been learned about expert team performance in the past 20 years. Below is a summary of the main points.

• Expert teams share a clear and common purpose and a strong mission.
• Expert teams share mental models. Their members anticipate each other. That can communicate without the need for overt communication.
• They are adaptive. They are self correcting. Their members compensate for each other. They reallocate functions. They engage in a cycle of prebrief-performance-debrief, giving feedback to each other. They establish and revise team goals. They differentiate between high and low priorities. They have mechanisms for anticipating and reviewing issues and problems of members. They periodically review and diagnose team effectiveness and team vitality.
• They have clear (but not overly clear or rigid) roles and responsibilities. Members understand their roles and how they fit together
• They have strong team leadership. Led by someone with good leadership, not just technical skills. They have team members who believe the leader cares about them. They provide situation updates. They foster teamwork, coordination and cooperation. They self-correct first.
• They develop a strong sense of “collective.” Trust, teamness and confidence are important. They manage conflict well. Members confront each other effectively. They trust each others intentions.
• They optimize performance outcomes. They make fewer errors. They communicate often enough, ensuring members have the information to be able to contribute. They make better decisions.
• The cooperate and coordinate. They identify team task work requirements. They ensure, through staffing and development, that the team possesses the right mix of competencies. They consciously integrate new members. They distribute and assign work thoughtfully. They examine and adjust the physical workspace to optimize communication and coordination.

We all (I hope) accept that quality and productivity in IT work can vary greatly from organization to organization, and therefore small expert teams can do better work faster than poor teams several times their size. This is unsurprising. This history of warfare shows the same thing.

With all our focus in IT on various ways of organizing projects, we seem not to focus on how to organize people. After all, we call it “agile project management” not “agile people management” or “agile team management.” We seem perennially predisposed to avoid talking about people directly and prefer to use a more inert surrogate concept like project. Or we prefer to keep conversations about people in largely tacit form, reserving more objective discussions for concepts like project.

Why do we talk so little about these “softer” team skills? When IT people do talk about these topics, the discussion usually surfaces sophomorically as complaints about “management” or “human nature” or “politics.” Should we “objectify” these aspects of expert team performance? Are managers capable of this themselves or do they need help? Do our agile methodologies take into considerations the factors above? Should they? Will methodologies or approaches silent on these largely tacit factors elicit expert team performance? What kills efforts to establish great teams?

A penny for your thoughts…

More to come, especially on what kills expert team performance.