.png)
Complete visibility into time & dollars spent
Create meaningful reports and dashboards
Set targets and get notified of delivery risks
Track and forecast all deliverables
Create and share developer surveys
Align and track development costs
Large software teams, those needing to order more than two pizzas for lunch, are regularly held up as examples of what not to do when it comes to getting code out the door faster. Social experiments, anecdotal reports, and even Harvard Business Review all come down on the side of smaller teams being more efficient.
But we’re here to tell you that larger teams can maximize their code throughput by using the right metrics, processes, and a healthy dose of out-of-the-box thinking. Here are our best strategies for getting the most out of large software development programs.
It’s impossible to evaluate team throughput or velocity without some kind of measurement system in place, and that’s even more true for larger teams that can be siloed, disjointed, and potentially even working at cross-purposes. Luckily, there are three sets of metrics teams can use to measure the process, the teams, and the value created.
Arguably, the most popular software development metrics are from the DevOps Research Assessment or DORA. The five DORA metrics – deployment frequency, lead time for changes, mean time to recovery, change failure rate, and reliability – provide a way for teams to look hard at areas most at risk for delays. The DORA metrics also function as a scorecard; based on the results, organizations’ DevOps efforts are rated high, medium, or low performers.
When it comes to looking at a large team through the metric of throughput, two DORA metrics are likely to matter most: deployment frequency and lead time for changes. Deployment frequency reflects how often a team is able to push to production, while lead time for changes looks at how long it takes a code commit to go live.
In its 2022 Accelerate State of DevOps report, the DORA team took a more detailed look at throughput, combining the deployment frequency and lead time for changes metrics, and mapped it to four stages of operational performance: starting, flowing, slowing, and retiring. Those in the “flowing” stage – just 17% of all surveyed – performed well across all types of operational performance metrics including throughput. In fact, teams in the flow were deploying multiple times a day, or “on-demand,” and had a lead time of code changes of less than one day.
Ideally, large teams should have the DORA metrics built into their processes so everyone involved can get an up-to-the-minute look at performance status.
Looking for a nuanced understanding of your DORA capabilities? Check out what Allstacks can do for you.
While the DORA metrics focus on the process of software development, another measurement framework, SPACE, provides a way for managers to view individual developers or development teams. Developed by Nicole Forsgren and other DevOps experts, SPACE looks at satisfaction/well-being, performance, activity, communication/collaboration, and efficiency/flow.
SPACE metrics are particularly useful with busy, larger teams where it can be hard to spot bottlenecks, burnout, collaboration difficulties, and more. Managers can have regular check-ins with team members to explore the following SPACE metrics:
A recurring complaint about development teams of any size is that they’re completely out of touch with the business goals. That’s likely even more true for large teams – with so many moving parts, it can be tough to get everyone’s attention. That’s where flow metrics come in. Flow metrics are a structured way to map software development to the things that matter most on the business side. There are six flow metrics – velocity, time, efficiency, load, distribution, and predictability, and, when implemented correctly, they can bring both development and the business side to the same table and in the same shared language.
Large teams looking to maximize throughput should pay strict attention to flow velocity, a metric that follows how much work has been done in a set period. Flow velocity is often used to track a team’s development backlog to see what work has been accomplished during a sprint or iteration.
It bears repeating: Large software development teams hoping to push the throughput envelope really cannot go wrong implementing all three sets of metrics, because each looks at a different slice of the overall endeavor. To put it another way, with these three metrics, large development teams can run, but they won’t be able to hide… anything.
Large teams wanting to move more quickly and efficiently also need to embrace the concept of developer velocity, a term used by McKinsey & Co. as part of its Developer Velocity Index. Developer velocity isn’t just about speed but rather a broader way to foster developer enablement. “The companies that have mastered developer velocity focus equally on empowering the developer, anticipating critical enablers, aligning investments with customer value, and minimizing barriers to productivity,” according to the 2021 McKinsey report, Developer Velocity at Work.
In its survey of 440 large enterprises, McKinsey found four areas to be particularly critical: culture, tools, product management, and talent management. When it comes to culture, McKinsey recommended a steady cadence of surveys, meetings, and one-on-one conversations between managers and developers to identify areas of concern before they become serious problems. The consulting firm also stressed the need for best-in-breed tools because there is no point in having fast-moving teams paired with slow-moving and out-of-date tools. The areas of product and talent management are of course trickier to master, the report said, not the least because management often doesn’t really understand what a developer’s work-life actually entails. “Product management remains a stumbling block, even for the best,” the report summarized. In terms of talent management, McKinsey stressed the need for employers to explain the organization’s value proposition in real-world terms so it’s meaningful to developers.
Large development teams are, well, large, and with that comes the possibility of organizational clutter, communication confusion, and inefficient processes. Not much is more demoralizing to teams than feeling ineffective and blocked at every turn. So to truly jumpstart throughput, pull the team together and walk through every step of the development process, noting what works, what doesn’t, and what could be better. And then start the (likely painful) process of change, dismantling what doesn’t make coding easier and creating a playbook of what is more efficient.
And be open to some experimentation, whether it’s pair programming, test-driven development, machine learning assistants, or cross-functional training. Large teams, in particular, can fall into routines that may not be the most effective so this is an opportunity to shake things up.
(Bonus: if presented correctly and supported sufficiently, trying new things can actually be fun, and breathe new life into a weary team.)
Finally, be open, but slightly cautious as of course too much of anything is never a good thing. Teams suddenly tasked with learning new processes, new tools, and new ways of doing things may be overwhelmed, meaning the changes will actually slow development down. Make sure to choose the Goldilocks “just right” approach.
Well-known developer, writer, speaker, and Agile expert Martin Fowler suggests organizations wanting to improve throughput should move from a top-down structure to one that’s more focused on developer guardrails, improved communication, and individual initiative. The end results – shorter feedback loops and happier developers – will improve all facets of software development.
Collaboration is at the center of all successful and high-performing software development organizations, but as team size grows, collaboration can become stretched thin, siloed, or break down completely. It’s next to impossible to force a team to collaborate, but it is key to at least understand some of the stumbling blocks.
A study from Carnegie Mellon University and the Federal University of Minas Gerais, conducted in late 2020, found a number of factors that can hinder software development collaboration. The report, Understanding Collaborative Software Development: An Interview Study, surfaced some insights that are particularly relevant for large software teams:
While focusing on big-picture productivity improvements for large teams, it’s also key to not leave out smaller steps that can help a team come together more quickly.
Large software development teams can maximize their throughput, but it will require measurement and metrics, as well as a hard look at the status quo and a willingness to make potentially significant changes. We always recommend organizations start with metrics, because without measuring, it’s impossible to know how well or poorly a team is doing. But don’t forget the other steps, like attention to developer velocity, a frictionless environment, lower key governance and a solid understanding of collaboration. It’s work worth doing, even if you do have to order three or four pizzas.
Looking for more Allstacks insights?