How to Manage the Growing Pains of Scaling an Agile Team

One of the biggest challenges of developing a digital product is accepting that your core development team may not be enough to get a complex product out the door quickly. Agile and scrum provide a framework for lean development, but what happens when it’s time to ramp up production from proof of concept to large-scale digital product?

It’s dangerous to assume that the same team patterns will be appropriate at every size of product development. For instance, you may think that if a core team includes two designers and two back-end developers, then a team three times that size must have six designers and six developers to deliver three times more.

Unfortunately, that is rarely the case for teams that need to rapidly scale production. It’s one of the dangers inherent to scrum: what works for an established agile team may not work when you need to expand.

Building Your Superteam

The biggest driver for team growth is – you guessed it – product growth. Once project scope grows beyond a certain point, your team will need to grow with it, as we encountered with a client who needed an automotive sales prototype. A single agile team delivered a proof of concept with basic functionality, which led to a new engagement for a rapidly growing complex digital product.

We knew early on that the single development team would not be enough to build the product quickly enough to get to market, so we began to scale our typical team up to a size large enough to design and build the heavyweight auto ecommerce platform.

We doubled our team size, and that doubled our output. Then we tripled our core team. Before we knew it, we had a superteam nearly five times as large as our standard development teams working together in one codebase, out of a single backlog, and it began to create significant challenges for the team and the product.

Hard Truth No. 1: At some point production will peak, and then it will plateau. It will be frustrating to see delivery slow, especially while using the framework you knew well.
When you begin to scale a product team, you’re going to hit a number of predictable – yet manageable – roadblocks. Here are a couple we encountered:

- How can you effectively measure velocity with a team of 20+? How do you account for differences in specializations, effort pointing scales and varying standards for metric tracking?

-Daily standups with so many hands in the pot started to burn significant development time. How can you save time and still keep the team updated on sprint progress?

-Product Owner attention was spread across the multiple features in progress. Can you feasibly secure design approvals for new features with development scheduled in the same sprint?

-Larger stories generally take longer to develop. How can you keep QA resources from getting swamped at the end of sprints?

Sprinting Through Your Product Roadmap

Every digital product we build is guided by a product roadmap. Product strategists work directly with clients to develop a firm vision that guides development by helping to narrow down a minimum viable product for initial release, prioritize features for future sprints and position clients to thrive in their market. While this can be useful when a Product Owner cannot devote his or her full attention to a project, it’s also an invaluable guide to scaling your agile team and allocating resources properly.

A product roadmap offers the opportunity to set goals at every level of development: daily standup procedures, mid-sprint check-ins, high-level feature release plans and sprint goals that must be finished for launch. Working in larger three-week sprints gave our superteam the opportunity to track goals and predict the necessary composition of the team as we moved through development.

You may need additional UX/UI designers early on to assist with digital prototypes, or extra back-end developers for engineering and database architecture as the product grows. The needs of the product should help dictate the makeup of your team.

As long as you have a clear understanding of your product roadmap and your team members’ strengths, you can add or subtract team resources as necessary without too many surprises.

However, relying too much on the specializations of your individual team members can become a pitfall.

The Problem with Subject Matter Experts

During a long development process with a large team, members of the team will naturally build product knowledge bases – they’ll become subject matter experts. You’ll have someone who deeply understands the brand design, another who ruthlessly hunts down bugs, maybe another who’s a mobile wizard. Experts are inevitable on any project, and they’re typically tremendous assets for an agile team.

However, as you scale an agile team (and the work it must produce), teams can become complacent and assume that your SME will handle any task associated with his or her knowledge base. It can be too easy for developers to fall into a mindset of “that’s not my specialty, but I’m sure he or she will get to it.”

That assumption is distinctly non-agile, and taking a step back to remember basic agile and scrum principles as your team grows can help remind everyone that they’re still, well, a team.

Hard Truth No. 2: The team dynamics that work for a team of 5 will probably not work for a team of 25.

The Solution is Right Under Your Nose

No matter how well you’ve planned for changes, however, the fact remains: a scrum team of 5 can operate much more efficiently than a team of 10, 15 or 20. That’s just simple team dynamics: mo people, mo problems.

But there’s good news.

Scrum already offers everything you need to get to a healthy development state. Here’s the obvious (yes, obvious) solution: Hold retrospectives every sprint, without exception. Try new solutions and make adjustments to your process.

Hard Truth No. 3: Your retrospectives may become painful. You might feel discouraged. You might doubt whether your superteam will find scrum justice.

And then you’ll start experimenting with potential solutions based on the needs of your team and your product. When you identify potential solutions in retros, focus on a few to implement and dive into during your next sprint. Some things won’t stick, and some problems will stay problems for several sprints. Keep your head up: over time, you’ll find strategies and workflows that meet your needs.

Here are a few that worked magic for us:

Just a note: if you’re not a hardcore scrum nerd, skip ahead to get a sense of what appropriate scrum scaling can do. If you are, welcome! Put your scrum hat on and dive in.

Team Member Specialties: It may not make sense to expand your initial team roles in a linear fashion. Growth should be circumstantial: multiple new features coming down the pipeline may call for an extra UX designer to balance the load, but if the new features are tech-heavy, it may be wise to allocate open team spots to skilled back-end developers. While a beautiful user experience is ideal, a broken experience is a broken product. Use your product roadmap to make smart decisions about your next team addition.

Effort Pointing Scales: We had to define a level point baseline to unite the multiple pointing scales from new teams added to the project. We chose a relative ~5 points for each developer per development day and set story examples, not hours, for that measure.

Particular Strength Velocity: We couldn’t reasonably use past sprints to calculate team velocity since the team structure had changed considerably each sprint, so we used the following equation:

Breaking user stories down into front-end and back-end elements will help match effort points to velocity and determine a more accurate sprint forecast.

Daily Standup Length: Rather than timeboxing the full group’s updates, we created a Google spreadsheet with a list of user stories, one tab per sprint day, that each distributed team could access to comment on progress from the previous day. If the forecasted story had an update, it was discussed in standup, and if not, it was skipped. We reserved all major roadblocks for the end of standup and released any roadblock-free developers before holding those longer problem-solving “Parking Lot” discussions.

Design Approvals: Development was moving so fast that there just wasn’t enough time for our Product Owners to review and approve feature designs on top of their other sprint responsibilities. We decided to break out our design team into a separate adjacent project team for new features to be designed, reviewed and approved an entire sprint before development. The designers soon became valuable story owners, helping to write acceptance criteria and answer developer questions throughout development.

Quality Assurance Overload: We beefed up our QA team to get more hands available for both in-sprint and regression testing. We planned a Pencils Down stopping point for new development followed by 2 full days of testing to give the QA team more time to tackle the inevitable flood of completed stories near the sprint’s end. Developers were available to fix any remaining in-sprint story issues, and some even began working on existing bug fixes for testing and launching with the next sprint.

Hard Truth No. 4: You will not get your first attempt at scaling agile perfectly correct. You’ll hit roadblocks and new challenges, but you absolutely won’t improve without transparent dialogue and process experimentation.

The results speak for themselves. We used to start slow and struggle to achieve our sprint forecast. Now our superteam is firing on all cylinders.

Your Next Superteam: Keep These Things in Mind

Consider breaking the large team up into smaller teams, potentially with multiple Scrum Masters. Depending on your project, you might split developers up by specialty, site feature/epic or even by release date. Remember: the smaller the team, the more manageable, with 7+/-2 being ideal.

Retrospectives are priceless. Never miss an opportunity to talk openly and honestly with your team about what’s working and what isn’t. Determine the most important issues and set goals for improvement in the next sprint.

Stay open-minded and remember to breathe. Scrum for 5 developers just isn’t the same as scrum for 25. You’ll need to adjust your mindset and process along the way.

Brush up on the basic agile principles you already know. You’re on a team. Communicate, support each other, ask for help and you’ll be amazed at how readily solutions will appear.

The above are ideas that have worked for us at 352, but it’s certainly not a comprehensive list. What are some tips you’ve learned from scaling agile? I’d love to hear from you!