Back to resources

Scaling Agile in Large Dependent Teams Setups

Scaling Team
Agile / Scrum

15 September, 2021

Gaurav Sharma
Gaurav Sharma

Engineering Manager at GlobalLogic

Gaurav Sharma, Engineering Manager at GlobalLogic, shares his valuable insights on how independent teams are the backbone of agile at scale.

Problem

“Agile teams need short backlogs of small items, a number of which are quite well-articulated and socialized, but only just prior to the iteration boundary in which they will be implemented.”

― Dean Leffingwell

The popularity of agile maturity can be dated back to 2010, 10 years after the agile manifesto was written. Agile was initially recommended for team sizes of 7 - 12 people, but after its popularity, the scale started to increase gradually.

Many times we work within different teams that have their own goals and backlog but they all work within a big portfolio and product initiative. So basically we need a model where 10 different teams are working together and overall team strength can be over 100 people. Those teams are often interdependent, and it is nearly impossible for them to operate independently.

Even though these teams and organizations operate in an agile manner, there are challenges. It can be seen that they are not as efficient as they seem, or there is no framework. As the era of scaled agile came into existence, more versions of it also became prevalent, which gave a framework of how organizations should work together when operating at a scale.

It is certainly not recommended for the startup culture. Fortunately, I had a chance to work on a project where about 150 people worked in 12 agile teams. I was managing 2 agile teams and working with other groups on setting the plan on a daily basis. While I read about agile teams theoretically in the past, this was my first hands-on experience to apply those principles.

Actions taken

As mentioned earlier, projects are the big engine in agile teams, and we don't know who's doing what. My takeaway from this was that I managed the data well enough. Everything is still pretty small in a scaled agile environment, where I could email someone, talk to them or easily manage things before it goes out of hand. However, dealing with a larger group (~ 150 people) meant having a formal approach and having data. I had to make sure that the real-time data was visible, and I created some JIRA dashboards to get a view of different areas.

It was pretty fantastic because the dashboard represented and gave some visibility. For instance, if 10 people were working on a joint initiative, the overall progress was 50%; to break that down, 10% was by team A, 20% was by team B, and Team C was waiting on others and so on. Whether it was the engineering or the product leadership, this type of visibility was extremely important because they could make further decisions based on that. Needless to mention that those decisions had to be overly concentrated because a small mistake could lead a big team towards a blunder. Initially, people were not thinking about the dashboard, but from my leadership perspective, it did help.

Referring back to the main problem, 一 which was dependencies 一 we had so many things working together, and the need to lean on other teams was impacting productivity. We slightly restructured the teams; so, the team doing a bit more work than the others saw their challenges and split the group. Logically, the independent changes that could be made then were done by other teams. Even though we are using Agile - we can always refer to the other standard Project management principles to solve such problems. Two main things I implemented were creating a Gannt plan with WBS and identifying the Critical paths.

In a few cases, we noticed that the bottleneck was caused by the product's design. Therefore, we also brought some engineering changes to our architecture. Noticing the complexities being built on the same core module, we discussed it with our customers to optimize and decouple things efficiently. For developers, that was relatively easy; dealing with the operational challenges and analyzing them to re-engineer some of the areas did help to some extent.

I found inspiration in "Team Topologies: Organizing Business and Technology Teams for Fast Flow" by Manuel Pais and Matthew Skelton and some other quality materials. It gave me some ideas to deliver sustainably and how to build one of the best team organizations. There has to be a core kernel team that is only focused on keeping the product architecture in the best shape and accommodate common needs in an efficient way, while there could be separate teams to handle minor updates and CRs.

Lessons learned

  • Look for help when you need it. If you are not clear about something, refer back to some established formats instead of being hesitant before implementing something. Management is one of those areas where people are not keen on reading or learning, but there's no end to learning. In a nutshell, do your research and apply the best practices.
  • Dependencies will always be there, especially in the case of bottlenecks and distributed teams. Since you can't avoid them, the right way to handle them would be to create a forecast; make data available, and be prepared for roadblocks. Again, make things more visible, which will eliminate chances for any surprises that impact scaling.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

How to Streamline Your Recruitment Process for Quick and Effective Hiring

26 May

Philip Gollucci, Director of Cloud Engineering at CareRev, describes a new method for hiring in a market climate that favors candidates instead of recruiters.

Scaling Team
Building A Team
Hiring
Philip Gollucci

Philip Gollucci

CEO/Founder at P6M7G8 Inc.

Managing Culturally Diverse Remote Teams

11 May

Tom Hill, Engineering Manager at Globality, Inc., shares how he works with a culturally diverse team based within a thirteen-hour time gap.

Scaling Team
Handling Promotion
Remote
Onboarding
Hiring
Cultural Differences
Tom Hill

Tom Hill

Engineering Manager at Torii

Hiring the Right People: Looking Beyond Just Technical Skills

25 April

Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, describes his lessons after hiring on technical merit alone and shares how a revamped hiring policy helped him find the right people for his team.

Scaling Team
Building A Team
Hiring
Matias Pizarro

Matias Pizarro

CTO and VP of Residents at ComunidadFeliz

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.