While many of the thought leaders in the Agile community decry the inexorable march toward banal, brand-oriented adoption, entreating us to internalize the principles of Agile and not blindly follow prescriptive practices, proscribing such phrases as “being agile” or “doing agile”, there remains an elusiveness to what makes Agile work. We’ve heard the stories: high-functioning teams churning through a product backlog, steadily delivering week after week. Nothing impedes these paragons of Agile values, while the rest of us struggle.
The picture looks quite different for most Agile teams: stories are estimated inaccurately; pair performance varies widely; velocity suffers at the mercy of technical debt; knowledge silos emerge; defect cycles lengthen; customers start getting frustrated. Very soon managers start trying to identify problems with the process, invariably looking for their keys under the lamplight instead of where they dropped them—looking for problems they can solve instead of solving the problems.
One cold Chicago winter night, Robert C. Martin, “Uncle Bob”, related a tale wherein a company engaged in the adoption of Scrum saw a very promising early spike in velocity followed by decline. They brought in Ken Schwaber, looking for the problems in their Agile practices and methodologies. With some tweaking they saw another bump in velocity but were too soon again swimming upstream. The Scrum Master himself next recommended they bring in Uncle Bob. They had done all the Agile stuff right—everything but the engineering.
As Uncle Bob relates the tale, Extreme Programming (XP) neatly codified the marriage of what we now call Agile with fundamental, essential software engineering principles and techniques. Unfortunately, most managers have very little aptitude for or mastery of the engineering, and naturally focus on those things they perceive they can directly impact. Consequently, the Agile aspects got top billing, and the engineering relegated to understudy. The unequivocal result is underperforming teams and projects. Agile made them dumb.
“Whoa! What about those teams who are delivering,” I hear you ask! Those fabled unicorns of the software industry where every iteration delivers substantial business value and change is accommodated like an accidental in a Kind of Blue reprise… surely they’ve got the system right. Or, maybe it isn’t the system at all. That’s the pretext of the Agile guru’s foreboding about “doing Agile”—there is no system, no prescription… There’s just really smart, wise, motivated people working together effectively.
Organizations are driven to Agile practices for a number of reasons, but few managers would suggest that Agile makes their teams smarter. But that is truly the secret sauce of what makes so-called Agile teams successful. They have a high collective intelligence. As a group they can overcome a great many obstacles and continue performing at a high level. They create fewer problems for themselves and deal swiftly and precisely with the problems they don’t create. They work.
Recent research into high-performing teams—those with a high collective intelligence—shows two distinct and surprising facts. First, individual intelligence is only weakly correlated with team performance. Second, there is a strong positive correlation with the number of women on the team and team performance. Women make teams smarter than men. Full Stop.
Why? Those of us with a Y-chromosome will be relieved to know that there is a similar correlation with social sensitivity and team performance. Women generally rate significantly better at social sensitivity than men. The researcher states, "what it suggests is that if you don't know the social sensitivity of a group, it is a better bet to include females than not." "The team also found that groups in which members took turns speaking were more collectively intelligent." (New Scientist)
In most enterprises, groups develop software. The engineering aspects of software development are extremely difficult and require a great deal of intelligence. It stands to reason the groups with high emotional intelligence are better at developing software than not. A bunch of hotshots don’t make for a smart group. So how would we go about maximizing the collective intelligence of development team?
“…took turns speaking…” Sound familiar? Stand-ups and pair programming, when effectively fostered, should result in an effective increase in the social sensitivity of the individuals on the team. The corollary is that teams that are good at stand-ups and pairing are better at delivering software. Agile makes them smarter.
Managers should be cogitating on ways to increase the social sensitivity of their developers. To those that can’t break their addiction to quick fixes: fire all the asshole, prima dons and use the windfall to hire some competent women.