Improving Accountability and Predictability of Delivery in Agile Teams
In Henrik Kniberg’s Agile Product Owner in a Nutshell video, he draws the 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 have to 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 replaced it with “the team.”
Build the Right TEAM
Most managers will immediately think of hiring the right knowledge workers who are a fit for the product, the culture, and are good team players. Sure, those things are important – but there is a rather compelling MIT study that shows teams with less knowledge but greater emotional intelligence out-perform those that are made up of just those that 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 are proven 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 course. 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?
Taking a look at the history of the United States government may give us insights. The US government began with a small number of motivated individuals who wanted to effect change. It devolved into a highly complex system requiring literally hundreds of politicians to communicate with each other 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?
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 who 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=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.
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 backwards into forming, norming, or storming. There is tremendous advantage in leveraging the already-performing team, in addition to avoiding the costs incurred by potentially breaking another one. 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.
Managers who find themselves mentioning words like accountability and predictability may benefit from reframing the team problem in terms of agile value management. When we build the right team and build the team right, accountable teams who deliver at a predictable rate follows.