“Team” should never be a metaphor or a euphemism for a random group of people; it should instead imply working together as a unit. But in everyday use, “team” implies success. In the absence of success, fault or failure is characterized as residing with an individual — preferably an unknown one — or with some undetected bug in the system. In our culture: Teams win; individuals screw up.
For example, in racing, victory is always accomplished by teams. For everyone else, perhaps the driver may assume personal blame (“taking one for the team”) or perhaps someone, somewhere, let the team down. A political candidate’s victory reflects the wisdom of the people; her defeat is always a personal blow, and some operative’s career usually ends there.
“People talk about teams succeeding and teams failing,” states Dr. Rashina Hoda, who teaches software engineering at the University of Auckland, New Zealand. “And somehow they forget or overlook the fact that they need to actually decide whether what they’re talking about is really a team, or if it’s just a group of individuals. There’s a whole team theory about how to organize teams, and so on, but the sense of the identity of the team as one team, and as a real team, is really important. And that includes the aspect of colocation, and the aspect of not being duplicated across projects and working together on one project with a common goal.”
We want it both ways. As managers,we want our teams to be successful. We also want individuals to be empowered (especially ourselves), and individual initiatives to be valued. While each of us wants to be part of something larger than ourselves, we also desire appreciation for something more unique and precious than merely what it is we belong to.
Team Empowerment and You
Our comfort level with dichotomies can be gauged by our hearts’ ability to be equally warmed by two contrary viewpoints from two distinctively dissimilar Georges. General George S. Patton’s (corrected) speech to his troops reads, “An army is a team. It lives, sleeps, eats, and fights as a team. This individual heroic stuff is pure horseshit.” And a quote from an equally skilled master of colorful language, George Carlin, states, “I like people who buck the system: individualists. I often warn kids, somewhere along the way, someone is going to tell you there is no ‘i’ in ‘team.’ What you should tell them is, maybe not. But there is an ‘i’ in independence, individuality, and integrity.”
One of the 12 derivative principles of the initial “individuals and interactions” proclamation of the Agile Manifesto suggests that left to their own devices, individuals form teams by nature: “The best architectures, requirements, and designs emerge from self-organizing teams.” (Mr. Carlin, meet Gen. Patton.)
Yet, dichotomies can lead to beneficial action for both the individual and the collective. As a recent sociological study of self-organizing teams shows, when teams do successfully organize themselves, its members tend to assume roles that may be commensurate with their personalities — roles with, on a deeper level, emerge from what Carl Jung ascertained to be their psychological archetypes.
Armies of One
Dr. Hoda, whom I introduced to you in “Agile Often Isn’t,” uses sociological methods, especially including Grounded Theory, to learn how people behave when they attempt to adopt Agile. In a 2010 paper, “Agile Undercover: When Customers Don’t Collaborate,” written with her then-colleagues at Victoria University of Wellington, she revealed that software developers’ efforts to employ Agile methodologies can easily lead to the breakdown of the interactive processes that Agile’s creators so loftily upheld. However, when developers adjust the application of Agile’s principles to better suit both the developers and their customers, the results turn positive.
In a separate paper that same year entitled “Organizing Self-Organizing Teams,” Hoda shared her team’s observations (See? a team success!) about development departments that follow the Agile principle of self-organization and also actively share a common goal. In our talk, she reminds me that it’s improper to actually call the groups she studies “teams” unless they actually achieve team status and produce teamwork — which is not a given. “Becoming a team takes time. It’s a project,” she says.
“Absolutely the first and most important balancing act that an Agile team must perform is between freedom and responsibility,” she goes on. In Scrum-style self-assignment, for example, team members choose assignments from a list on a whiteboard, as opposed to a manager specifically delegating tasks.
“Here comes the balancing act,” she says. “As an individual, when you walk up to the board, you have the freedom to pick up whatever you like. But you have to keep in mind not just your team responsibility, but a number of responsibilities. One: the responsibility for your customer. You should pick tasks that are of the highest business value to the customer, not just the ones you think you will enjoy the most, or the stuff you think will help you add on to your résumé.” Those are the connotations of that freedom. But, she points out, a responsible individual member of a self-organizing team displays responsibility when exercising that freedom.
Though they may not go about this process consciously or intentionally, individual group members employing Agile for the first time, Hoda’s team found, tend to adopt one of six roles:
A mentor articulates the goals of the team to members of the team directly, helps guide them in perceiving a common vision, and boosts their confidence by giving them signals (which some call “controls”) when things are going right.
A coordinator serves as the team’s direct connection with and representative of the customer, articulating the customer’s needs to the team. This alleviates the need to hire a “customer proxy,” often from outside the team, to placate the customer when things go off-track, as Hoda’s team discovered in “Agility in Context” (PDF available here).
A translator helps team members interpret the logic and principles of the customer’s native organization. As opposed to the coordinator, who keeps the project “on-message,” a translator seeks to clarify the underlying issues and the thus-far unforeseen circumstances relevant to the project.
A champion articulates the goals and mission of the team to senior management... everyone’s senior management, including the team’s own. That includes everyone who may be disassociated from the day-to-day aspects of the project but may still hold the power to stop it.
A promoter is a person who carries the Agile banner, who professes its key principles, and when in doubt or in the event of dispute, consults Agile evangelists for a solution.
A terminator (yes, you immediately thought of Arnold Schwarzenegger; personally, I’m thinking Kyra Sedgwick) is someone who drives to get the job done, especially in the clutch, and who has the requisite nerve to recommend that certain... individuals be cut from the project if necessary.
“Where self-organizing teams work, people go against all kinds of odds and come up with all sorts of strategies,” Dr. Hoda tells me. “And a positive note that comes out of my research is: People are keen to take the best of [Agile] and adapt the not-so-good of it, or things that don’t fit so well, to make it work in their own context.”
Critical Utopia
Rashina Hoda’s studies illustrate the natural tendencies that can manifest themselves once freedom and responsibility are appropriately balanced. Dr. Likoebe Maruping of the University of Louisville participated in a separate sociological study on Agile and the use (or lack thereof) by team managers of control theory to influence members’ behavior. That study reveals that, although the Spider-Man story joins freedom with responsibility, they rarely play nicely together.
While teaching at the University of Arkansas, and with a colleague at the University of Maryland, Maruping found statistical evidence that Agile development teams tasked with self-control typically don’t exhibit it. What’s more, he theorized that the cause for this phenomenon may be the native disparity between “team” and “individual,” both in terms of value and of priority.
“Exercise of self-control was found to be detrimental to the relationship between Agile methodology use and project quality,” the Maruping team wrote. “The use of self-control undermined the benefits of Agile methodology use in software development teams. This presents an interesting dilemma for managers because software developers are typically compensated for their unique skills and abilities.”
One cautionary tale that comes from this particular piece, Dr. Maruping tells me in an interview, is “When you look at this self-governing approach, where individuals are self-regulating and self-monitoring without there being an overall set of mechanisms, we found this has very negative implications from a quality perspective.”
Maruping acknowledges that individual group members do need to feel personally empowered to believe they’re successful. Yet he also warns that it’s critical that team leaders (a role whose characterization Agile typically frowns upon) determine at what level this empowerment should occur.
“Academic literature would distinguish between psychological and structural empowerment,” the professor says. “Structural empowerment would tap into [the question of]: To what degree do I have autonomy to make my own decisions about the tasks I’ve been assigned? To what degree do I have decision-making authority? The indication is that, as you start working on tasks that actually are dependent on inputs and outputs from other individuals, that becomes a less desirable mechanism for governing individuals. It’s much more desirable from that perspective to have empowerment at a higher level — at the level of the team, as opposed to the individual.”
Maruping suggests that an Agile team should have authority as a unit to make certain decisions, and that members within that team deliberate over what those decisions should be. The danger here is that power centers can form, shaping the decision-making process to suit its exclusive purposes, and polarizing authority toward certain individuals. The same people who fall into one of six neatly defined roles under Dr. Hoda’s balanced circumstances, could make plays for power under these imbalanced circumstances.
To that end, Maruping suggests: Put a management system in place to maintain the collective nature of the team’s efforts — to distribute the responsibility. But to avoid the creation of autocracies (part of which sparked the Agile Manifesto in the first place), teams should consider distributing the leadership among multiple people... maybe a triumvirate, or perhaps a kind of executive central committee.
United forever in friendship and labor, our mighty team will forever endure... You have to admit, it does ring a bell. Manifesto, anyone? I asked Dr. Maruping, doesn’t this system of distributing authority (and centralizing the means of its distribution) sound a little utopian? “In a way [yes], which would be a good characterization of where this is moving towards from a governance perspective,” he says.
Regaining Control
The hope is that individuals who belong to a software development organization may forge a team from a group, by following their own personal natures — the roles their psyches, to use Jung’s term, would lead them to play. But fulfilling a role and fulfilling a responsibility are two different tasks, and there is no patentable method for ascertaining responsibilities through the fulfillment of roles. Nor is there likely to ever be one.
Every organization has its own unique context, and the mandates of neither Agile nor any other systematic methodology apply to all organizations equivalently. But perhaps, just as a physicist values the data obtained from studying particles and from studying waves but never both at once, the solution to the broader task of empowering teams is to value the individual uniquely, while valuing the team as a unit just as uniquely.
“An organization,” wrote Peter Drucker in his monumental treatise Management, “will have a high spirit of performance if it is consistently directed toward opportunity rather than toward problems.” Four paragraphs later, Drucker defines Dr. Maruping’s word, control: “An organization that wants to build a high spirit of performance recognizes that ‘people’ decisions — on placement and pay, on promotion, demotion, and firing — are the true ‘control’ of an organization. They, far more than the accountant’s figures and reports, model and mold behavior.”
If that is true, then the practice of Agile would, by definition, remove the system of control from the organization, eliminating one’s place in the org chart, the pay scale, and the food chain as incentives for advancement. Perhaps that explains why Maruping discovered an absence of controls in the organizations he studied. Agile does not specify any system of control that should suffice as a substitute, though perhaps Dr. Hoda has shed light on a solution: First, balance the organization, giving the team unit and the individual unit equal weight and consideration. Then, enable human nature to do what human nature does best: slough it out.
“Don’t ever let up. Don’t ever think that your job is unimportant. Every man has a job to do and he must do it. Every man is a vital link in the great chain,” pronounced Gen. Patton, three minutes later, in the very same speech. I guess this individuality stuff isn’t a bunch of crap after all.
See also:
