Optimising team structures

Mar 6, 2017

As a software consultancy, TrikeApps optimises for output and developer happiness. We have experimented with several team structures over the last three years. In our experience, the least effective teams are multi-disciplinary teams with high rotation. The most effective teams have a more narrow focus and stable membership. Predicting the effects of achieving sprint goals boosts developer happiness. Read on for more about what we’ve observed about team structures.

Happy developers are productive developers. Everyone wants to go to work and feel like they’ve achieved something important at the end of the day. For developers, this means having the mental space to go deep on problem solving. Minimising interruptions is critical. We also try to narrow sprint goals to be stimulating without becoming overwhelming. Team size has a strong influence on interruption levels and the scope of sprint goals.

At TrikeApps in 2014, everyone worked on everything. Individuals self-nominated to complete stories that clients were screaming the loudest for. Afterwards they would switch to the next loudest screamer. This was often in a completely different system and domain, incurring switching costs. Each week, the “interruptible” person rotated, answering support emails and phone calls. If the “interruptible” person was new, everyone got interrupted while they got up to speed. Needless to say, this did not improve developer happiness.

The first change we made was to split the developers into two client-based teams and a support team. One developer from each team would rotate each sprint. This meant that a rotation on a client team would last as many sprints as there were team members. The support team handled emails and phone calls. The support team was also responsible for urgent smaller-client work. We saw an immediate increase in output. Developers appreciated being able to focus on a single client for a month or two. And yet, regular rotation still incurred switching costs and story handover costs. The support team still found things challenging.

To reduce switching and handover costs, we doubled the length of the rotations. Now, a developer from each team rotated every two sprints. This was great for the client teams. Output rose again, and developers in those teams reported greater satisfaction. The look of dread on the faces of those about to rotate into the support team told a different story. We had divested our smaller clients but our support team still felt unproductive. We refocused the support team on solving problems at the root cause. We made it easier for them to pass work to the client teams, and things got a little better.

After observing the pattern in output and developer happiness, we dropped rotation completely. The trend continued. As we were growing the team, we made the support team the entry point for junior developers. We documented common problems and subject matter experts on our wiki. Junior developers addressed simple bugs and delegated more complex tasks. We had these developers nominate regular times for learning activities and feature work. During these times, other team members handled support duties on a volunteer basis.

Our most recent change was to have the teams organised by a broad sprint goal. One of our clients has grown to the point that the client team was three times the size of the other teams. The systems managed by that team grew to the point that task switching was becoming a problem again. We cut down our team size to three developers each. Each sprint, we look at the backlog and identify common overarching themes. Our team leads decide on an achievable overarching goal on each theme. Narrowing the focus gives each developer more ownership and more satisfaction. An interruption from a team mate incurs less switching costs. You’re both working in the same narrow domain.

We also have our team leads record a prediction with a judgement date. If they achieve the goal, what will that mean for TrikeApps and the client? Often, a sprint goal is to reduce TrikeApps’ busywork by building tools so a client can do common tasks themselves. For example, building a feature that allows the client to edit site copy. With a goal like this, it is easy to forget to measure the reduction in busywork when that freed-up time is quickly filled with other tasks. Measuring, and celebrating the wins, gives the team a sense of achievement.

TrikeApps’ team structure is still an experiment. While our team and our clients continue to grow, we’re likely to face new challenges. By trying things and measuring the results, we can ensure that we keep moving in the right direction. How do your team structures work, or fail? What experiments have you run? We’d love to hear about it.

<< Back to blog post listing