Need uber-guru types who are willing to challenge the existing groupthink on design and architecture, especially on TDD and emergent design and pair programming anti-pattern” – job post at Monster.com 2/9/2010
I stumbled upon that quote following links on the role of the architect on an agile project. Maybe one important role of the architect is to help the team avoid groupthink.
Groupthink is a situation where a team’s decision process breaks down and the team reaches decisions that aren’t fully vetted and evaluated. Both Watergate and the Bay of Pigs fiasco are cited as examples (here). I’ve seen groupthink operate on IT projects, and to me the agile method’s effectiveness in enabling groups to work together means agile projects are particularly susceptible.
This post reviews groupthink then discusses how the architect on an agile project might help prevent it.
From the Wikipedia article on groupthink, “groupthink is a type of thought exhibited by group members who try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas. Individual creativity, uniqueness, and independent thinking are lost in the pursuit of group cohesiveness. During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking…Highly cohesive groups are much more likely to engage in groupthink, because their cohesiveness often correlates with unspoken understanding and the ability to work together with minimal explanations.”
In my experience risk of groupthink can manifest in several ways on IT projects:
- Not Invented Here: Successful teams that work through conflict can settle into a shared culture that resists new ideas from outside the team.
- The Know It All: Less successfully integrated teams can be dominated by a single strong-willed individual, and can habitually avoid conflict by accepting without question the ideas of that one dominant team member.
- The Abilene Paradox: Team members sometimes collectively decide on a course of action that no one on the team likes, when each member actually disagrees with the decision but mistakenly believes that their own preferences are counter to the group’s.
The Agile Architect
According to the Psychologists for Social Responsibility, the standard remedies for groupthink include this: “At least one articulate and knowledgeable member should be given the role of devil’s advocate (to question assumptions and plans)”. Of course the architect is an integral part of the overall project, but the skilled practitioner participates with the Agile team while maintaining separateness in order to remain a source of ideas from outside the team, and therefore provide a counterweight to groupthink by recognizing it and taking measures to prevent it. Andrew Johnston’s site agilearchitect.org describes some of the ways the architect is in but not totally of the team (here). Among the architect’s responsibilities, he or she:
- Ensures “the delivered system is consistent with the agreed architecture, and will meet the requirements”
- “Is frequently an evangelist for new or different technologies, processes or solutions”
- “Acts as a bridge between developers, managers and other communities, and spends much of his time translating and mediating between them”
- “Recognizes the wide range of stakeholders, and their needs and concerns.”
While core agile team members are immersed in the scope and design that defines the current sprint, the architect retains a larger perspective that encompasses alternative designs, emerging technologies, business fit, stakeholder concerns, and more. The architect is therefore uniquely positioned to recognize groupthink effects on the team’s technical activities. Here are two examples of how that works on agile projects:
- Estimations and retrospectives: Mark Needham, in this post, cites risk of groupthink in agile estimation sessions and retrospectives. The architect can address both of these risks. In estimation, the architect brings the diverse perspective that Mr. Needham says is important when team members estimate incorrectly due to incorrect team-shared assumptions. In retrospectives, the architect can be the one to increase the “safety” of different perspectives by raising or encouraging others to raise “things that have gone well, not gone well, and things that are confusing”.
- Work product reviews: I’m an advocate of code walkthroughs and design reviews, and making them explicit sprint tasks. The team can set aside an hour or two a week to review one or two representative work products in order to share ideas, ensure quality, and uncover overlooked errors or opportunities. In this forum the architect has the opportunity to reinforce quality work that is aligned with the requriements and architecture, or supportively correct deficiencies.
Of course there are risks:
- The architect shouldn’t be the know it all: In some cases the architect can be the strong-willed individual who stifles creativity and causes the team to avoid conflict. Strong teamwork and interpersonal skills are core to the agile method, and those who staff the project must include those skills in selection and evaluation of the architect.
- Keep the architect different: If the architect is a core member of the team, he or she can become integrated into the group and therefore part of a groupthink dynamic. For this reason, I advocate architects being assigned part-time to agile efforts. Otherwise, the architect risks becoming the extra developer, as near term sprint tasks expand to fill the available team bandwidth. Consider sharing the architect among two or three projects, or assigning him or her responsibility for technical strategy and planning.