In Henrik Kniberg’s Agile Product Ownership in a Nutshell video, he draws a Venn diagram that illustrates what agile teams are challenged with every day: building the right thing, building the thing right, and building it fast. Ideally, we want to stay in the Zen-like balance of having all three in equal parts. The trouble is, building software is a team sport and teams are made up of humans, not robots (no offense to robots). We must focus on the people to understand the team and its performance if we want to stay within the nucleus of the agile Venn.
With that as our goal, let’s take our concept of building “the thing” 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 right knowledge workers who are a fit for the product and the culture and who are good team players. Sure, those things are important—but a rather compelling MIT study shows that teams with less knowledge but greater emotional intelligence outperform teams that are made up just of people who are highly knowledgeable. Yes, that’s right: Hiring the “most qualified” candidate does not necessarily mean hiring the most knowledgeable or experienced. For software development, it means hiring the person who is most likely to help their team solve problems, not to know all of the answers. Emotionally intelligent teams prove to be better at solving problems together, which results in better software.
Build the team right
We know how important it is to have an engaged product owner, a team that understands the product vision, and mechanisms for validating direction. Great teams will also create working agreements, a definition of “done,” a clear cadence for their work, and a way to continuously improve. They’ll self-organize around these essentials and deliver value at light 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 us insights. The US government began with a small number of motivated individuals who wanted to effect change. It evolved into a highly complex system requiring literally hundreds of politicians to communicate with one another effectively if they want to implement any changes at all—but who are so worried about staying in office for their limited terms that they spend most of their time fundraising.
There are several things that jump out in this example. For purposes of building the team right, I am focusing on two: size of the group and 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 every person’s name? How about other details like their jobs, their spouses, the color of the shirt they wore?
Chances are, you can remember a few people’s names. You may even remember other details for four or five people you met. Beyond that number (unless you’re blessed with amazing powers of recollection), those details are not usually retained. The same thing happens on a team: The more people there are, the harder it is to remember the details of what each person is working on and whom it may impact. The more the communication paths increase, the greater the chances of disconnects and misconnects.
Personally, the most effective teams I’ve ever seen were made up of four to six people—but this requires getting out of the mindset of “person equals role.” A small team can share in the responsibilities of a role; 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 be fostered by environment, and team size is a container that management can influence while still supporting self-organization.
This raises questions around how to have the smallest team size while also having the appropriate number of teams for the product or service being delivered (and an optimized workflow between the teams). That topic deserves its own article, so I won’t tackle it in this one. I will just add that, in my experience, solving the logistics challenges of workflow between teams is (perhaps surprisingly) a simpler problem than those caused by having 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 be reallocated. This incurs a cost, because even if the team members are distributed to other currently performing teams, adding a new member to a performing team will frequently A) result in a team that is larger than optimal and B) send the performing team backward into “forming,” “norming,” or “storming.” (Editor’s note: See the Wikipedia page on Tuckman’s stages of group development for an explanation of this team development model.)
There is tremendous advantage in leveraging the already-performing team, in addition to avoiding the costs incurred by potentially “breaking” other teams. Retention rates increase because relationships are kept strong. Predictability of delivery improves because the team already knows how to manage their work and solve problems together.
I have also seen advantages in training an already-performing team in new skills, rather than disbanding them because the new project or feature requires something they aren’t experienced in. Again, it is more advantageous to have a small, long-lived team of competent individuals who can learn new things than a large group of recently assembled experts.