Why Agile Teams Work
Why Agile Teams Work
An in-depth summary and explanation of "The Wisdom of Teams" by Jon Katzenbach and Douglas Smith.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
“The Wisdom of Teams” was first published in 1993, written by Jon Katzenbach and Douglas Smith. Based on years of research and field experience as a McKinsey consultant, Katzenbach and his co-author Smith formulated six “team basics”:
- Small number
- Complementary skills
- Common purpose
- Common set of specific performance goals
- Commonly agreed upon working approach
- Mutual accountability
Katzenbach and Smith called teams that exhibited these attributes “real teams”. More than twenty years later, I call them agile teams. The six “team basics” clearly coincide with agility.
The small number theory has morphed into Mike Cohn's “two pizzas” idea, or the “7 + / - 2” theory all agilists have heard, but the underlying concept remains. The communication and consensus overhead of large teams inhibits innovation and throughput. Complementary skills are demonstrated in the integration of Dev and Ops, where two sets of competing values are combined into one continuous delivery stream. They’re also exhibited in intentional cross-functional teams, where the right skills and traits are combined to produce a valuable outcome. Common purpose is now a vision statement. Performance goals are now roadmaps, iterations and valuable features. Scrum (or whatever practice you’ve chosen) is the common working approach. Mutual accountability is manifested in the big visible charts by which we measure ourselves, by our collaborative skills, and by the kaizen manner in which we approach reflection and adaptation.
The key attributes of effective teams revealed in this classic text show that the team concepts within agile didn’t just appear, and that real-world observation proves these team fundamentals valid. Katzenbach and Smith showed that, at the team level, there are some well-known success factors that improve results. The success of the agile movement has finally made these ideas, which seem the opposite of real life in the typical big company, accepted as “best practice”.
In the typical corporate culture, these concepts are new and foreign. Before agile, IT professionals worked in large, function-based silos, with database experts on one team and Java coders on another. The team all had similar skills, instead of complementary ones. Lack of coherent corporate communication and team collaboration often made the purpose of our work opaque. Performance goals were nearly always individual, not team-oriented. Every team in every organization had a distinct working approach, and, in many old-line firms, accountability was remote, lax, and arbitrary. The hierarchical, command-and-control management style of the 1950’s has left residual mindsets and practices that are naturally resistant to agile evolution. But evolve they must, if businesses hope to survive. Agile coaches, consultants, and internal advocates must adapt to the resistance of old habits and determine unique ways to nudge control-based enterprises towards lean, agile, collaborative teams, practices, and mindsets.
The results of teaming successfully and adaptively, from Katzenbach’s time to ours, are so strongly validated and so compelling that enterprises can’t resist. Most also can’t do it alone, at least not yet. As agility migrates across levels, helping managers and executives understand, accept, and support these team concepts is an agile change agent’s big challenge. Migrating the first, small team to agility isn’t trivial, even in an enthusiastic group of like-minded and like-dispositioned coders. As we ascend the organizational ladder, motives become less transparent, and individual or division interests come to the fore.
Guiding Dev and Ops to a continuous delivery cycle is tough enough. Getting sales and marketing to collaborate, or siloed division heads to team up cross-functionally, is a whole ‘nother thing. From agile organizational design, to team, tribe, and squad theories of teaming, the agile change agent will need to adaptively apply multiple, various team formations as she engages across the enterprise. Agile evolution at the enterprise level stirs up multiple interdependent layers of disruption and change. The composition, objectives, styles, and expectations of development teams, operations teams, marketing teams, finance teams, risk-management teams, and executive teams will differ sharply.
The "team basics" of Katzenbach and Smith make a good foundation, like the principles of the Agile Manifesto. How we apply them in an agile context is individual to the situation. The iterative, evolutionary process of advising, reflecting, and adapting agile teams, top to bottom of the enterprise, is, like all kaizen practices, eternal.
Opinions expressed by DZone contributors are their own.