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.

build-agile-superteamBuilding 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.

agile-team-roadblocks

  • 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?

LH-Map-75

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.

screen_shot_2015-02-25_at_2.38.02_pmYou 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

dog-treat

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 the charts below to get a sense of what appropriate scrum scaling can do. If you are, welcome! Put your scrum hat on and dive in.

team_horiz

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:

mmdvelocity

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.

See a difference? Yeah, us too. We used to start slow and struggle to achieve our sprint forecast. The sexy, lean burndown chart on the right is the superteam 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, but it’s certainly not a comprehensive list. What are some tips you’ve learned from scaling agile? We’d love to hear from you!

  • http://softwarerocks.tv/ Andrew Binstead

    So I started writing this comment last night, but stopped myself because I didn’t want to come across as just being mean. But we have talked quickly on twitter so here is my thinking.

    This is only my opinion, this has worked for you and something working is more valuable than any opinion. Agile is hard to do right, scaling agile is even harder.

    But why did you want to build one super team? Why not split the teams down into smaller teams, you even say yourself 7+/-2 is the best bet (I would say 4-7 is best but again opinion). Then break the one product down into smaller products. Frontend, backend, admin, etc. Then you have more discreet products that each team can work on.

    The product owner still keeps control of the whole thing but gives product owner power to trusted others (maybe your UI/UX people). Each one of them has the responsibility of looking after their product, but the PO keeps responsibility for the whole thing.

    That way you don’t loose the stand-ups, each team has their own, and the product owners (and maybe a technical person from each team) has a scrum of scrums to make sure everyone is on track.

    Yes there is a lot of coordination but that is also true of having one super team as well, the work hasn’t changed, the roadmap helps with a lot of that. Then you are more easily able to split the testing and not have the idea that you have to stop 2 days before the end of the sprint to make sure the testing happens. I am a little of a purist perhaps when it comes to QA, all testing should be taking place as the development is happening, and regression testing must be automated.

    There are a lot of ways you could dice it, perhaps the bit I’m having problems with is where you have one super team.

    • Kate Griggs

      Hi Andrew,

      I agree with everything you’ve said.

      We did have some specific team splits: we broke out the design team completely, and divided dev teams up between new work, bug fixes and database refactoring stories. Our ultimate goal with the product was to transition our work and processes to the client’s internal team. To help them establish workflows and best practices, we wanted to work with them from the start to create a team structure that they could emulate and move forward with in their non-agile world. It was certainly an adventure to work with them to find ways to “keep it scrum” and in hindsight there are some things we could have adjusted, but the superteam made up of standard-size teams transitioned well into the changes, and kept delivery consistent with our sprint schedules.

      Do you have any specific ideas from your experiences on how best to tackle this in the future?

      • http://softwarerocks.tv/ Andrew Binstead

        Hi Kate,

        There is no right or wrong answer to any of this stuff is there. Not only are the problems you face always different but the make up of the team and what happens after the project has completed is always different.

        The only thing that I think I do differently is I always aim to have cross functional teams rather than specialist teams. I want to give my development teams purpose and let them own their software rather than feeling they only do one part of it. Vertical slices of the application or splitting the application.

        No matter how you attack it communication is the key, and that is where I want really strong technical product owners who can keep it all together.

        Having to hand it back to a company that isn’t agile is always a challenge, especially once the teams have started understand what being agile is all about.

        If you could do it again, what would you do differently?

        • Kate Griggs

          Ah, yes – we actually found it immensely helpful to establish two Product Owners, a technical PO working with engineers on development and refactoring, and an industry expert PO working with designers to hash out new features and commandeer sprint plans.

          I think the main thing I would change is the way we increased team size. Over time, we learned which developers would fit where and how to utilize their strengths to keep project onboarding to a minimum… but I think we could have further refined our product roadmap to better predict feature needs and make longer term decisions about which team additions made the most sense for the project.

  • http://invisume.com/ elwood smith

    Hi Kate awesome work here. Most businesses follow a team of individuals all clamoring to be heard and I really love the idea of splitting the team into little sections per expertise and to never forget setting goals. Team building is also another great way to boost productivity.

    • Kate Griggs

      Right on, Elwood! What types of team building are the most valuable to you?

  • http://www.mystechdynamics.com Mystech Dynamics

    I totally agree with splitting the super team into smaller teams. In that way, you can delegate the tasks to the these leaders and let these leaders to their thing on their respective teams.

    • Kate Griggs

      Absolutely. Once we determined there were more than 3 or 4 subsections of the product, we knew it was time to split responsibilities to have multiple Subject Experts thrive in their specific environments – Masters of Some instead of scattered skills across the board.