This is the second in a two-part series about adjusting Agile practices for larger teams. In Part 1 of this mini-series, we took a look at how individuals and interactions impact Agile practices. In Part 2, I’ll share what we’ve seen in the other areas. Confession: Most of these points still come down to individuals and interactions because that’s the difference between a smaller and larger team–the number of individuals and thus interactions.
Delivering Working Software
It’s harder to clarify requirements
On a smaller team, there are typically fewer people involved in determining the requirements for a feature. We often have one person (usually our Delivery Lead) who serves as the primary contact for questions about requirements and has a reasonable chance of being able to answer them.
On our medium-sized team, the chance of any one person being able to answer a question about requirements is greatly reduced because of the number of people involved in determining those requirements. It might be one of our subject matter experts, a designer, or our product owner. It can take longer to get the requirements clarified because of the number of people potentially involved.
To combat this issue, we’ve started recording more information about which person on the team is the best resource to clarify specific stories or epics.
It’s harder to pull off a major refactor
There are constant merges to our main line of development and many ongoing parallel tracks of work. It can be a half-time job just to keep a major refactor branch reasonably up-to-date with developments. This ripples back into the ongoing work when it gets merged, and it can take days to resolve. The only solution we’ve found is to accept the complexity, over-communicate, and aggressively coordinate.
More coordination of merges and releases
Simply because of the amount of work we’re covering in parallel, we need more coordination to manage merging and releases. It hasn’t been a problem or felt too overbearing, but we’re continually aware of it.
Responding to Change
When you’re steering a big ship, it takes more time and power to change direction.
If we want to shift focus to a different area of the application we’re building, a larger development team needs more “sprint-able” work in that other area before they fully shift focus. For our team, some of the early design research and planning work is single-threaded and takes more time than later phases of story refinement and breakdown. That means that it can take more time to respond to a change like that.
We’ve broken our research, design, and planning pipeline into a few distinct stages. Each stage of that pipeline needs to have a healthy backlog ready for action so that the team is able to adapt to changing plans.
Scheduling
On a larger team, scheduling has been more difficult because more people tend to be involved in any given discussion or team ceremony. What has helped our situation is that most of our team members are full-time and 100% dedicated to our project.
There are situations where we can’t get everyone we want involved, so we have to trust that those who are present will do the job well.
What about Splitting the Team?
Have smaller teams!
Okay, sure. That would probably avoid some of the challenges we’re facing as a larger team, but that’s not always an option. We wouldn’t knowingly take on a project where team size jeopardized the project’s chances of success. But, when we work with a client team, changing the team size might not be the most productive place to focus. There are still healthy ways to approach building productive Agile practices within a medium-sized team, even if a smaller team is preferred.
And I haven’t attempted splitting a team yet. If we’re working on one application, we might not know how to split the team in a way that still meets our goals.
Even if we don’t know the axis along which we’d split the team, there are some things we know we’d want to accomplish:
- Separate codebases to allow development to run independently. (A shared library–or a few–is likely.)
- Separate CI, deployments, etc.
- Separate product owners.
- Pursue the completion of one functional milestone at full speed.
Some ideas we’ve considered:
- Split front-end and back-end.
- We don’t like this approach because it creates a lot of dependencies between the two teams. We prefer to set up the development team in a way that lets them deliver a completely working feature.
- The problem may be exacerbated by our implementation strategy of thin React app with rich back-end. We expect the back-end development to be more significant than the front-end.
- Split functional areas of the application.
- This isn’t ideal because we’d like to complete one whole functional area of the app before moving on to another. Splitting the team could slow progress to any one functional area being completed.
- On a positive note, this could be a reasonable way to get the codebase separation we’d like.
- Split application work and integration work.
- There is going to be a lot of integration work for this application. Beyond some early planning and research, we haven’t started it yet, but it’s going to be significant. We’re concerned that it might be a feast-or-famine workload.
- This would achieve a codebase-level separation between the application’s view of its own world and the twisted worlds of other systems, preventing leakage of those external system domains into our application.
- Overall, it wouldn’t be a slam dunk. But it could work.
Conclusion
Thanks for sticking with me through the last two posts. We’re still working on more improvements to our team’s working model to make the best use of our talents and time. I’d love to hear how other people have approached applying Agile approaches to larger teams, especially stories about splitting a team— successful or otherwise.