4 Secrets to Successfully Scaling Agile Tech Teams

According to a McKinsey Quarterly study of software development organizations around the world, the top-performing companies created software upward of three times more productively and had a 70 percent shorter time to market for new products and features than the bottom-performing companies examined.

This is a huge advantage. It means companies that figure out how to make software a competitive advantage are the ones that are going to come out ahead in the next decade and beyond.

So, the question becomes: What’s the best way to expand a tech team so it continuously develops software productively?

Here are four secrets to success that hundreds of agile organizations I’ve worked with have used to scale their tech teams.

Secret 1: Be Deliberate about Process

Regardless of the process you start out with, be deliberate about choosing it and accept the fact that your process will change as you grow.

Last year, my company, Stride, was called in to help scale a team of four engineers. When we joined, the process was that there was no process. Each developer came into work and took whatever story he or she wanted to work on. Some developers tested their code, some did not. Some had code reviews, some did not. Even though the developers had a glorious sense of empowerment, this quickly turned into low morale because the team was missing deadlines. And as a result, the business was angry because it wasn’t confident in the tech team’s ability to deliver.

Stride came in and implemented an extremely lightweight initial process: daily standups and two-week sprints. Sure, there were tons of other things we could have done, but we deliberately chose these two basic things to start and intentionally didn’t change anything else for the first two months. And to begin with, it worked: Both the team and the business were happier knowing what everyone was working on.

This didn’t resolve all the issues, though. The company was a heavily funded tech startup on a hockey-stick growth trajectory. Within three months, the team of four had grown to forty. To respond to the growth, we formed cross-functional teams and created a kanban system. These process changes resulted in increased velocity and predictability. The business was thrilled and the team still felt empowered.

Rather than doing it all at once, we picked the two most valuable process changes, implemented them, and gave the team time to adapt to them. Only then did we implement more changes.

Pro tip: Every three months, re-examine your process. Create a calendar reminder to ask yourself if your process could use improvement or if it still meets your needs.

Secret 2: Hold Regular Retrospectives

I love retrospectives. In my experience, they are powerful for many uses beyond iterations, including business and strategy evaluations.

No matter how often or for what purpose you hold retrospectives, be sure to use a facilitator—ideally, someone who is not on the team but understands the team and its work. This can be someone on another team inside your company whom you regularly interact with.

Start off the retrospective by reading the retrospective prime directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Retrospectives are not about finger-pointing; the goal should be to focus on problems, not people, and finding effective solutions.

It is also helpful to have action items with due dates. Assign each action item to one person, not to multiple people, so that accountability is clear.

Pro tip: I recommend reading the book Agile Retrospectives: Making Good Teams Great. It details how to run effective retrospectives on an ongoing basis, so you don’t have to wait until the end of a project to learn what could have been done better.

Secret 3: Hire Slowly

While this secret may seem counterintuitive, it’s the best approach. Hiring slowly helps maintain high standards and a strong culture as you scale. Keep in mind that this doesn’t mean “respond slowly.” It means you should be continuously hiring, always looking for people you want to work with and keeping in touch with them.

I keep a list of all the amazing people I know whom I’d like to work with one day. It doesn’t matter if my current team has a need for their skill set or not. I make a point of reaching out to them every four to six months so that when the need does arise, we have open lines of communication.

There are several fun ideas for keeping in touch with prospective hires:

• Ask to buy them coffee so you can catch up
• Say congrats if they’ve moved jobs or had a child
• Ask them a favor
• Comment on a blog they’ve written
• Respond to a tweet 

The point is not that you are actively hiring them, but rather that you are in touch with them a couple of times a year. Then, when you have a hiring need, you have a rich personal network of people to choose from.

Pro tip: Never feel bad about emailing someone and asking if they want to work with you. You are offering them a job. This is flattering and appreciated, even if they say no.

Secret 4: Focus on Product and Engineering Team Communication

When teams are small, communication flows almost effortlessly. But when you scale, it becomes something you have to work at. It’s critical to focus on ways to ensure communication between teams remains efficient.

This is the single biggest problem tech teams run into as they grow. When project teams expand beyond about ten people, product and engineering teams stop communicating effectively and the entire system breaks down. Engineers start working on what they feel is most important without regard for what the product team wants, and the product team gives unrealistic deadlines and demands to engineering without regard for what the engineers want.

Nip this in the bud by being proactive about improving how these two groups communicate. If you don’t know what the strengths and weaknesses are of your inter-team communication, find out by sitting down with a cross-section of members from both your product and engineering teams and asking each person:

• What’s working well on our team now?
• What are our biggest areas for improvement?
• If you had a magic wand and could change one thing about our team, what would it be?

Aim to talk with ten to twelve people individually, ranging from the newest, most junior team member to the biggest stakeholder. If your team is smaller than ten and you’re still having communication problems, talk with everyone.

Then, review the results and look for trends. In my experience, you’re going to find gaps in communication, and the team members involved are the best chance for suggestions about how to close these gaps.

Having a strong product owner on the team is also a great help to maximize effective communication as companies scale. He or she must be physically and mentally present; a product owner who’s spread too thin or is remote is almost always less productive than one who’s on-site and dedicated to one project.

Pro tip: Team members are often afraid to be truthful when asked questions about communication problems by someone on their own team. Consider bringing in a third party, such as an agile consultant, to do the one-on-one interviews. This way, the interviewer isn’t a threat to anyone, and feedback can be made anonymous.

Scaling a tech team effectively is tough, but it’s certainly possible. Using these four secrets can help you succeed.