Agile Software Development and the Core Design Principles for Teams
I just came across a wonderfully scientific confirmation of the wisdom of agile software development teams.
The source was a surprising one: Evolutionary Biologist David Sloan Wilson’s latest book This View of Life: Completing the Darwinian Revolution.
The applicable knowledge comes in Chapter 8, “What All Groups Need.” Here’s the first paragraph that caught my attention:
Multilevel selection theory tells us that something similar to team-level selection took place in our species for thousands of generations, resulting in adaptations for teamwork that are baked into the genetic architecture of our minds. Absorbing this fact leads to the conclusion that small groups are a fundamental unit of human social organization. Individuals cannot be understood except in the context of small groups, and large-scale societies need to be seen as a kind of multicellular organism comprising small groups.
What this means is that, as human beings, we are hard-wired, not to compete and survive as individuals, but to work together cooperatively as members of small teams, with a maximum size of about 15 individuals: something that agile proponents have been preaching for close to two decades now.
But Wilson then gets much more specific, citing research done by Elinor Ostrom, the 2009 winner of the Nobel Prize in Economics, as well as a 2012 paper co-authored by Ostrom, Wilson and Cox, titled “Generalizing the core design principles for the efficacy of groups.”
Wilson lays out in his book, based on this published and recognized research, the eight core design principles (CDPs) that make the difference between success and failure of teams. I will paraphrase here.
- Strong Group Identity with Clearly Defined Boundaries. This includes a shared understanding of the team’s goals, the boundaries of their resources, and the rights and obligations of being a team member.
- Proportional Equivalence Between Benefits and Costs. Team members must be fairly rewarded based on their contributions.
- Fair and Inclusive Decision-Making. Everyone gets a chance to participate in decision-making, and decisions are made in a way recognized by all to be fair. Also, decisions are made at the lowest possible level, both to confer a sense of empowerment, but also to allow decisions to be made based on local circumstances best known and appreciated by the team itself.
- Monitoring Agreed-Upon Behaviors. The team must have a way of monitoring team members and detecting deviations from the team’s accepted norms.
- Graduated Sanctions. This may start as friendly pressure from peers, but then may proceed to more serious consequences if the negative behavior persists.
- Fast and Fair Conflict Resolution. When conflicts arise, teams must have a way to resolve them quickly and in a manner seen as fair.
- Local Autonomy. Teams must have the freedom to conduct their own affairs, generally free of externally imposed rules.
- Polycentric Governance. In large organizations that consist of multiple teams, relationships among teams must embody the same principles as the relationships among individuals within each team. This means that the core design principles above are scale-independent.
It’s interesting to note that Ostrom’s research was based on observations of the actual success and failure of many small teams, rather than on the invention of increasingly complex formulas and models often favored by traditional economists — certainly a vivid reminder of the way that Agile principles and methods came to be defined and accepted, often flying in the face of guidance offered by organizations such as the Software Engineering Institute and their Capability Maturity Models.
While Wilson’s teachings validate much of what Agile proponents have been preaching for some time now, they also provide a rigorous set of principles that can be used to evaluate any organization’s use of teams, as well as the operation of any particular team. This strikes me as valuable, because it can help free software developers from the sometimes insular guidance of one particular coach or manager, and potentially help resolve debates on these topics more quickly and authoritatively — an outcome right in line with CDP 6, as defined above.
I’ve excerpted some of Wilson’s work in this short piece in order to highlight material that should be of particular interest to software developers and their managers, but in doing so I certainly haven’t cherry-picked all the good stuff. I can enthusiastically recommend the entire book to everyone reading this, not just for its insights into the workings of teams, but perhaps even more importantly for insights into what it means to be human in the 21st century.
I’m always excited to find ideas and models that can be used across disciplines, and Wilson’s book amply delivers the goods in this department.
Originally published at PaganTuna.com.