Agile Teams: Build the Right Team, Build the Team Right

In Henrik Kniberg’s Agile Product Ownership in a Nutshell video, he draws a Venndiagram that illustrates what agile teams are challenged with every day: buildingthe right thing, building the thing right, and building it fast. Ideally, wewant to stay in the Zen-like balance of having all three in equal parts. The troubleis, building software is a team sport and teams are made up of humans, notrobots (no offense to robots). We must focus on the people to understand theteam and its performance if we want to stay within the nucleus of the agileVenn.

With that as our goal, let’s take our concept of building “thething” and replace it with “the team.”

Build the right thing—build the thing right—build it fast!

Build the right team

Most managers will immediately think of hiring the rightknowledge workers who are a fit for the product and the culture and who aregood team players. Sure, those things are important—but a rathercompelling MIT study shows that teams with less knowledge butgreater emotional intelligence outperform teams that are made up just of peoplewho are highly knowledgeable. Yes, that’s right: Hiring the “most qualified”candidate does not necessarily mean hiring the most knowledgeable orexperienced. For software development, it means hiring the person who ismost likely to help their team solve problems, not to know all of theanswers. Emotionally intelligent teams prove to be better at solvingproblems together, which results in better software.

Build the team right

We know how important it is to have an engaged productowner, a team that understands the product vision, and mechanisms forvalidating direction. Great teams will also create working agreements, adefinition of “done,” a clear cadence for their work, and a way to continuouslyimprove. They’ll self-organize around these essentials and deliver value atlight speed. Why is it that weeks or months later, we face disengagement,lethargy, or sheer lack of delivery?

Looking at the history of the United States may give usinsights. The US government began with a small number of motivated individualswho wanted to effect change. It evolved into a highly complex system requiringliterally hundreds of politicians to communicate with one another effectivelyif they want to implement any changes at all—but who are so worried aboutstaying in office for their limited terms that they spend most of their timefundraising.

There are several things that jump out in this example. Forpurposes of building the team right, I am focusing on two: size of the groupand longevity of their terms. Applying this to software delivery teams, we ask:How small should my teams be? How long should my teams remain together?

Team size

The last time you were at a party, did you remember everyperson’s name? How about other details like their jobs, their spouses, thecolor of the shirt they wore?

Chances are, you can remember a few people’s names. You mayeven remember other details for four or five people you met. Beyond that number(unless you’re blessed with amazing powers of recollection), thosedetails are not usually retained. The same thing happens on a team: Themore people there are, the harder it is to remember the details of what eachperson is working on and whom it may impact. The more the communication pathsincrease, the greater the chances of disconnects and misconnects.

Personally, the most effective teams I’ve ever seen weremade up of four to six people—but this requires getting out of the mindsetof “person equals role.” A small team can share in the responsibilities of arole; otherwise, we end up with the “not my problem” disease (aka “bystander syndrome”).Accountability isn’t something most people are just born with. It must befostered by environment, and team size is a container that management caninfluence while still supporting self-organization.

This raises questions around how to have the smallest teamsize while also having the appropriate number of teams for the product orservice being delivered (and an optimized workflow between the teams). Thattopic deserves its own article, so I won’t tackle it in this one. I will justadd that, in my experience, solving the logistics challenges of workflowbetween teams is (perhaps surprisingly) a simpler problem than those caused byhaving large teams.

Team longevity

When the feature is built or the product has shipped,management may view those team members who delivered it as resources to bereallocated. This incurs a cost, because even if the team members aredistributed to other currently performing teams, adding a new member to aperforming team will frequently A) result in a team that is larger than optimaland B) send the performing team backward into “forming,” “norming,” or “storming.”(Editor’s note: See the Wikipedia page onTuckman’s stages of group development for an explanation of this team developmentmodel.)

There is tremendous advantage in leveraging thealready-performing team, in addition to avoiding the costs incurred bypotentially “breaking” other teams. Retention rates increase becauserelationships are kept strong. Predictability of delivery improves because theteam already knows how to manage their work and solve problems together.

I have also seen advantages in training analready-performing team in new skills, rather than disbanding them because thenew project or feature requires something they aren’t experienced in. Again, itis more advantageous to have a small, long-lived team of competent individualswho can learn new things than a large group of recently assembled experts.

Conclusion