Much of what underpins agile software development is the power held by small, self organised teams to deliver. Contained groups of developers, testers, and designers are able to maintain much greater control of their own delivery, meaning that they are better able to solve problems together and continuously improve. The outcome of this is that we see small teams deliver great products time and time again.
Delivering great products usually means one thing: stakeholders want more development, and often faster. They want the same people to work to the same quality on their next business endeavour, and this often results in a team growing in size - and quickly.
So if we know that small teams win, how do you go about maintaining that successful mentality when your small team gets big? Spotify’s squad model is often held up as the gold standard, and even that’s been known to have its short-comings. Not all squads are good at managing their own delivery, and the boundaries between autonomy and ‘do what you like’ are harder to maintain at scale.
Sometimes when scaling a team it can be difficult to cut through the noise of frameworks and apparent ‘best practice’. At Kin + Carta we’re used to the demand on our small teams growing to the extent that they need to scale. Like with all delivery though, we believe that being pragmatic in your approach to scaling will set you up for success.
Growing gains: How to build big, effective agile teams
Understand the behaviour behind scaling pains
Before you jump right into planning frameworks and dependency management techniques, it’s important to get your head around why scaling teams struggle to maintain the same focus they did when they were smaller. There are two main behavioural acts at play: social loafing, and loss of coordination.
In brief - and there’s a tonne of evidence and research to back this up - social loafing is the phenomenon that the larger a group gets the more likely the individuals within that group are to think that someone else is doing the work. A great experiment by Maximillian Ringlemann shows that people put less effort into a task even as simple as pulling on a rope when the number of people they’re joined with on that task increases.
Loss of coordination requires a lot less psychological analysis. The cooks/broth proverb - that if too many people are involved in a task or activity it will not be done well - rings as true in software development as it does in 16th Century kitchens. When the team and their scope of responsibilities grow, they immediately become less constrained. Quite simply, it becomes more difficult to organise tasks while maintaining an appropriate degree of autonomy.
Pragmatically select the best parts of frameworks for your team’s needs
The common reaction to improving coordination within a team is to throw a framework at it. Put loads of structure, ceremonies and process around them and it’ll all work, right? Sadly not - and while there’s a lot of good stuff in scaled agile frameworks, there’s also probably a lot that isn’t relevant to your growing team. If you’re interested in knowing about some of the commonly used scaled agile frameworks, check out LeSS here and SAFe here.
The clearest example of this is in scaled agile planning (known as ‘PI Planning’ in SAFe). This typically takes place quarterly, and brings together co-dependent development teams to plan their work for the forthcoming period. We’ve found the work planning element of these ceremonies difficult to benefit from - it’s hard enough planning two weeks of work with clear requirements that remain relevant, let alone 12 weeks worth. However, the communication opportunity created by large group planning can be hugely beneficial for mapping dependencies between teams. By going into these exercises with a mindset primarily to mitigate loss of coordination, scaled teams can have their cake and eat it.
Use vision to keep teams self organising
Much of the success of agile teams can be attributed to their ability to digest a vision and autonomously turn it into deliverable work. This vision becomes harder to digest the larger the team becomes, often because it’s made more generic to maintain relevance to a broader audience.
While working with Kingfisher, a project that grew from 10 to 65 people in a little over 2 years, we found our greatest successes as a large team came when we were able to set mini-visions for a number of small teams (or squads). Key to this has been keeping product people at the heart of the process by scaling their head-count in ratio with the wider development team. In doing this we were able to have a team of four squads, each understanding their purpose and taking ownership over distinct areas of work.
Even better, is when the visions of multiple small teams clearly and tangibly relate to the vision of a broader whole. This requires strong communication of the story, and delegation from leaders to instil a sense of responsibility to the squad, but getting it right enables the team to act greater than the sum of their parts.
With several small teams all working towards the same goal, you’ll also be better placed to benefit from rotations amongst squads. This can be particularly effective when moving someone from a successful squad into one that’s struggling as they are able to share their learning and practises that have been so effective in the past into their new squad.
In summary, there’s a lot of power in scaling, and we’ve seen that it’s possible to maintain the agility of small teams while harnessing the collective power of the group - but you need to think about why it’s happening and how to do it. Teams that are set-up to succeed are ones that haven’t let themselves become bloated by process
In the face of change it might seem appealing to lean on a framework by the book, but given the impact these can have on a team’s ability to adapt and improve, it might be best to hold tight. Instead, make use of the elements of these frameworks and tailor your ways of working around your team and product’s needs. You’ll get better results in the long term.