Some of us on GitLab's Manage team had a discussion a while back about the challenges of staying agile while a company scales. In true GitLab style, the discussion took place asynchronously via an issue. Here it is:
How do you stay agile in a growing organization?
1. Make quick, but thoughtful decisions
Jeremy, product manager: This is the fundamental thing that allows startups to be competitive against dominant players in a market: It's using your resources more efficiently and moving faster than anyone else.
To me, two primary characteristics that support agility are making quick but thoughtful decisions, and focus. I think Amazon is a great example of the first, and I like Amazon's simple Type-1/Type-2 framework for identifying the Type 2 decisions that are easily reversed, and allowing the threshold of approval to be relatively low.
As companies grow, it feels like the perceived number of Type 1 decisions grows in turn – and the organization slows down as more decision layers emerge. One thing I love about GitLab is that we're still dedicated to moving quickly and we're not constantly asking for permission to make things better. If it's easily revertible and makes something better, ship it. In all honesty, I think this is one of our biggest competitive advantages.
2. Hire the right people
Liam, engineering manager: The interesting thing here is that lots of organizations (big and small) now realize the value of Agile ways of working (admittedly, many of which do agile but aren't agile), making it less of a competitive advantage and more like table stakes. Therefore, I think of Agile as the sensible (only?) choice when it comes to delivering your own product to customers. An Agile mentality lets you deliver incremental, low-risk value to customers, allowing you to get feedback or pivot with minimal investment.
I think the single most important thing for me here is hiring – hiring the right people who truly understand the value of agile ways of working.
One of the statements in GitLab's Efficiency value points out a particular behavior that is so important here:
Accept mistakes: Not every problem should lead to a new process to prevent them. Additional processes make all actions more inefficient and a mistake only affects one.
As an organization grows its headcount, the number of business processes invariably grows with it. It's very easy to add process as a knee-jerk reaction to a problem or because it makes you feel more confident in something being executed. Having a team question the value of new processes and perhaps ask "What do we lose by introducing this process?" is vital to keep agility.
3. Keep teams small and focused
Jeremy: I don't know if I agree that as an organization grows that business processes invariably grow as well. This is what I meant earlier when I mentioned focus; without smaller teams focused on problems they own, interests start to compete and decision-making slows down because more people have a stake in the outcome.
You can mitigate this with small, focused teams. This is harder in monolithic codebases with lots of dependencies between teams.
I do agree that hiring is critical to ensure everyone is questioning the status quo. The default answer to new process should be "no," unless there's some acute pain it alleviates.
Luke Bennett, frontend engineer: It is hard to avoid the reduction in velocity as a single team grows beyond some unknown threshold. A "single team" is a group of humans (or robots I suppose) making informed decisions about a cross-section of a product. As the team grows, it typically means the number of issues is already growing. There are more people accountable for those issues, more people making decisions on those issues, and more people contributing to those issues.
In software it also leads to team members working "at the same workbench" too often and of course makes the job of managing the team harder; even hosting a productive team call or keeping in touch with team members can become a challenge. This can easily lead to inefficient hierarchies to "patch" the problem, which can seem like a simple short cut compared to getting more Agile.
From my own experience, splitting a large team into smaller ones instantly provides a feeling of relief for team members. Of course it's not just about the size of the team, it's also about their responsibilities/scope. Team members desperately want to be contributing meaningful changes on time and a reduction in scope lets them focus again on a more specific cross-section of the product, shifting attention away from the larger team discussions that may not be specific to a product area. Put simply, a discussion between Manage product category members of 10 people will be much more product-focused than a Frontend discussion of 20 people. You can expect their contributions to be the same. Additionally, the chance to build a stronger connection and appreciation for your team members is not to be ignored. There are definitely productivity gains when everyone is on the same raft!
Team members desperately want to be contributing meaningful changes on time and a reduction in scope lets them focus again on a more specific cross-section of the product, shifting attention away from the larger team discussions that may not be specific to a product area.
I feel like this is a natural behaviour of humans. Agile feels natural to me at least and historically people never seem to work too well in very large groups. In the UK at least, we often reference the proverb "Too many cooks spoil the broth." It's a little more complex and less brutal than that in software development, but it stands.
That said, avoiding large teams can lead to more problems. It reminds me of Amdahl's law in that when you create more Agile teams, you create management overhead to orchestrate the direction of the teams. Agile with small teams is relatively simple because this effect is negligible, but as you scale your Agile organisation, you have to start paying attention to it.
4. Allow teams to experiment with their own processes
Sanad Liaquat, senior test automation engineer: To me, keeping the size of teams small and focused on specific areas with well defined scope/boundaries is very important to stay agile in a growing organization. Also, the team should be allowed to discover their own processes and evolve. This works very well when the organization has teams laboring on separate projects with separate codebases. Each Agile team/project can then share what works best for them with other teams which can decide to adopt the practice or not. When projects have dependencies on each other, it is important that there be effective coordination on release timings between teams.
With organizations such as GitLab, where there is a single codebase, teams having their own process is not pragmatic. I believe GitLab handles Agile very well by dividing the organization into 2D slices of teams (Frontend, Backend, Security, Quality, etc.) and groups (Plan, Manage, Create, etc.) and having well-defined processes shared across groups. I believe it is necessary to keep an eye on the size of the group and think about breaking it down if it grows beyond what is considered a small and effective Agile group. (How small is "small" would be a separate discussion.)
Jeremy: Yeah, I agree that small teams are pretty key. Sanad brought up dependencies, which is really important. You can have small teams, but if they can't operate independently you'll lose all your velocity.
It's interesting that you say that teams at GitLab don't have their own processes, because it feels like our teams DO have their own processes. We have some standardization like release cadence (monthly on the 22nd) and some labels (Deliverable), but we're free to do our own thing.
We operate differently than Plan and Create:Source Code, for instance. Plan uses the "due-22nd" label to split the work into two-week chunks, and Create:Source Code still estimates issues individually. I think it's a strength that we can individually experiment, but why isn't this more of a problem?
I do think that different teams have different needs. I feel like some processes work better for other teams – maybe based on the personalities of the people or the engineering/product maturity of that particular stage.
I don't know if we've really asked "why" or documented what's worked and what hasn't. I'm sure individual teams have experimented a lot, but I wonder if we're missing out by not tracking and sharing some of the things we've tried.
Sanad: I was not aware of other teams within GitLab having different processes like the ones Jeremy mentioned. I do agree that some processes can differ within teams and it is a strength that allows a team to experiment on their own and evolve as they deem fit for themselves. However, when working on the same codebase, it is better (or unavoidable) for teams to have uniformity on things like the code review process, testing strategies, documentation standards, etc.
5. Make sure everyone is on the same page
Martin Wortschack, senior frontend engineer: I also want to emphasize how important it is for an organization's leadership to understand what "Agile" means and that it's not just another fancy buzzword. It requires change. Depending on the organization it could mean anything including introducing new processes, hiring the right people, etc. Therefore it's very important that everyone involved has the same expectations and common understanding of "staying Agile" (or "becoming Agile") and understands the necessary steps that need to be taken towards being an Agile organization. The best talent won't be able to change much if their decisions are not backed by the executives. I've seen a lot of companies that would consider themselves an "Agile organization" just because they have set up a Jira project.
So, to me the most important thing is everybody's ability and willingness to change.
If you'd like to see more of these discussions around other topics, please let us know in the comments below or in the original issue.
