Building and maintaining a high performance software team is an ongoing effort. The challenges range from attracting great people in a highly competitive market, to providing interesting and challenging workloads, and putting together team structures and practices in which people can thrive.
We’re lucky to have worked with a number of software teams who have been looking to improve the quality and frequency of their delivery, and we’ve noticed a few recurring structures and embedded practices which hinder a team’s ability to ship good quality software fast:
1: “DevOps” silos
Particularly as a team grows, or perhaps to fill perceived gaps in the current team’s skill set, the temptation can be to build separate functions in or around the team to perform specific roles.
The most common manifestation we’ve seen is that of operations (often referred to as DevOps or infrastructure), where any infrastructure related tasks need to be performed by someone in this unit. We see this as adding an unnecessary boundary around a critical part of software delivery – deploying and running the thing.
We’d much prefer to see true DevOps skills embedded in the software delivery teams, empowering these teams to deliver their application end-to-end, and making them responsible for running it.
2: Lack of empowerment
We often observe a high correlation between a lack of empowerment and poor performance. A team needs to be able to manage their own workload day-to-day, be able to make technical decisions and, if necessary, to make changes to the way they work.
Where a team is fed small units of highly specified work, and where decisions are made top-down, is likely where you’ll find apathy.
We’ve found that teams perform best when they’re given a clear, commercially focused brief, and then empowered to figure out the best way to deliver it.
3: Isolation from stakeholders
In some organisations there can be structures or practices in place that discourage or make it impossible for the delivery team to have contact with stakeholders. A high performance team needs to have regular, open communication with those for whom they’re delivering the software.
On top of the usual forums for facilitating conversation such as kick-off sessions and showcases, we encourage the use of communication tools like Slack to foster ongoing discussion between stakeholders and developers.
4: Lone soldiers and large teams
We’ve found an optimal team size to be between 2 and 4 people. For most people, working in a team of 1 lacks the accountability and social interaction gained from working with others.
When a team size starts exceeding around 4 people, communication can become harder and team accountability reduces.
5: Quality belongs to everyone
An all too common response to challenges with quality is to try to solve this by introducing a dedicated role, or worse still, a testing silo. Where there’s a perception of a safety net between the team and the software running in production, responsibility levels drop and quality soon follows.
We’ve seen better success in encouraging quality as a team responsibility, embedding practices such as peer review and increasing adoption of automated test techniques.
6: Prioritising features over technical debt
There’s a balance to be had between delivering to commercial deadlines and keeping on top of technical debt. When not kept in balance, technical debt quickly hinders a team’s ability to deliver.
Teams being happy to accrue technical debt, or leaders being happy to turn a blind eye to it, are behavioural patterns that we immediately try to identify and improve when we start working with a software team.
A team needs to feel empowered and encouraged to sell the benefits of paying off technical debt to their Product Owner, such that technical debt can be dealt with alongside feature development.
7: Underinvesting in team building
It’s important to not forget the basics in building a cohesive team. Facilitating an array of social activities to provide forums for teams to enjoy one another’s company outside of a work setting, alongside opportunities for individuals to learn and better themselves remains ever important.
Improving the happiness, productivity and cohesiveness of any team remains an ongoing effort, and requires regular course correction. If you’re aiming to build a high performance software delivery team, we’d encourage hiring militantly well, and investing in practices that provide a regular feedback loop to help you embed a culture of regular introspection and improvement.
About the Author
Chief Operating Officer at Made Tech
Chris has 20 years’ experience in digital and technology consulting roles spanning public and private sector clients including Royal Bank of Scotland, Philips, Government Digital Service, and Ministry of Justice. Prior to Made Tech Chris was Technology Director at Dentsu Aegis agency Isobar, leading technology delivery in the UK. Chris has been with the Company since 2012.
