At Atomic Object, we prefer to work in small, self-managing teams (2-10 people). However, as consultants, we recognize that some circumstances necessitate larger teams. In those situations, it’s important to understand the trade-offs and consequences and work to mitigate them. Below are three common issues big software teams face and how you can work to mitigate them.
1. Understanding the System
One of the most likely reasons your team is large is because the system is both large and complicated. Early on in the product’s lifecycle, it will become too complicated for any one person to keep it in their head in its entirety. That’s all right, as long as you are proactive about mitigating it.
Mitigation Strategy A: Create a Domain Model
Domain-driven Design is a technique for mapping the business domain and terms directly into the software. Part of the technique suggests keeping a comprehensive drawing of the system, called a Domain Model.
The Domain Model allows every member of the team to speak the same language and understand precisely what each means. It’s something that team members can point to as they describe desired behaviors.
This mitigates the problem because it turns the system and its vocabulary into a tangible artifact. We can zoom in and out as needed and see how everything in the system is related.
Mitigation Strategy B: Document Business Requirements
On smaller teams, I’ve favored documenting business requirements in user stories. On larger teams, where a project is long-lived (12+ months), there are too many iterations on requirements to keep stories a viable documentation option.
In that situation, I would end up piecing together stories in a particular area, resulting in a fuzzy picture of the current behaviors. It didn’t give me or other team members confidence. This led to more interruptions of developers to get a true picture of what is implemented, taking valuable time away from them delivering software.
To mitigate this, you should document business requirements outside of your user stories. You should refer to wherever that documentation lives within relevant stories. In my experience, maintaining a section of Confluence with business requirements and linking to those sections from user stories has been an effective way to go.
2. Too Much Work in Progress
It’s inevitable that with a big software team a lot of code is being written all the time. If 10 developers write code for six hours a day for a week, you’ve generated 300 hours’ worth of code.
The last thing we want is idle developers, and the bigger the team gets, the harder it is to find work for everyone.
Mitigation Strategy A: Parallelize as much as Possible
The common solution to keeping a large dev team fed is focusing on several different areas of the application simultaneously.
In my experience, this causes more harm than good. Both developers and business team members are constantly context switching to solve problems. All the context switching leads to miscommunication, which eventually leads to re-work.
Instead, I like to invest developer time in finding ways to parallelize efforts in just a few areas of the application. The upfront cost is recouped by reducing the chances of miscommunication that leads to re-work.
Mitigation Strategy B: Make Priorities Visible
If you’re receiving feedback from your team that they’re feeling stretched too thin or if you are seeing an increase in missed or unknown requirements, I strongly encourage you to take time to list out all of the team’s current priorities.
This exercise is helpful in multiple ways. First, it’s good to radiate this information constantly. This makes sure the team is in alignment about what the focus should be on. Second, and most importantly, you’ll likely find that there is a lot of priority work in-flight, more than there should be. You can use this list as a tool to set expectations within the team and rein in the focus to fewer areas.
3. Team Loses Sight of the Big Picture
A ton of micro-decisions happen on projects each day. Sometimes it’s developers choosing a particular architecture style over another. Other times it’s the business team opting for the more complex choice out of a pool of options.
When software teams get big, it becomes more difficult to keep everyone’s mindset on the bigger picture. It’s cumbersome and expensive to have an all-hands-on-deck meeting, so we choose not to. But, I would argue that it’s a lot less expensive to have those checkpoints than it is to rebuild an entire feature set because a design decision was made that could have been avoided with a little more understanding of the broader goals.
Mitigation Strategy A: Team Charter
I strongly suggest that your big software teams create and maintain a Team Charter. This serves as your team’s North Star when it comes time to make decisions that have tradeoffs. It creates team purpose and goals and lets the team define how they want to work together.
Mitigation Strategy B: Milestone Kickoff
In a long-running project, I suggest gathering the entire team at the onset of each new milestone. Use it as a time to reflect on the previous milestone. Gather feedback on what went well or what processes can be improved. Use it as an opportunity to dive into the next milestone, the objectives, and the exciting opportunities it will enable for users.
Winning Strategies for Big Software Teams
At Atomic, we prefer to work in smaller, efficient teams. When teams start to grow, problems are magnified. If you are in a situation where a larger team is necessary, awareness of these common pitfalls and mitigation strategies will hopefully pay off for you and your team in the long run.