Skip to main content

How to Lead Multiple Agile Teams Without Sacrificing Sanity

How to Lead Multiple Agile Teams Without Sacrificing Sanity

I have been leading Agile teams for some time now and working at Gorilla Logic for almost a year. One of the most impressive things I have seen thus far is the capacity this company has to lead multiple projects at multiple levels in an Agile way. In theory, this may sound easy-peasy, even common sense, but in practice, it can be a huge challenge.

Of those challenges, the most common ones are: 

• Delivery is not what the client was expecting

• There was a problem and it was not mentioned in time

• There was a dependency from another team that was not mentioned until the last minute

In order to overcome those challenges, I have a few recommendations in case you have one or multiple teams to lead.

Create an environment with great communication and full transparency 

Good communication will always be the most important part of any team and the best way to reduce risks. When a company decides to engage in offshoring, good communication can be extremely difficult. Large differences in time zones, language barriers, and cultural differences stifle communication frequency and mean a higher risk of a failed project. The stakeholders are spending money in another part of the world expecting to receive what they have in mind, even though their visibility and control may be limited. Scary. Gorilla Logic specializes in nearshore outsourcing; we know the easiest way to avoid unnecessary risk is by creating an environment in which great communication is seamless. Time zone alignment, English-fluency, and cultural affinity make communication between clients and within teams easy. Teams and clients speak regularly explaining issues/blockers, estimation for deliverables, and status updates. Gorilla Logic’s Agile teams are experts at optimizing channels such as Slack, Skype, and email so that everyone is constantly aware of all changes and progress. This constant communication helps avoid missed information and sets the team up for successful Sprints

Schedule meetings with all your teams in mind

I am currently the Scrum Master for four different teams all with the same client. The most important decision, in this case, was to make sure all of the Scrum ceremonies at the end/start of the Sprint (Sprint demo, Sprint Planning, Sprint Retrospective) must coincide. This is a principle from the Agile Release Train theory from SAFe¹: “The more alignment you have, the more autonomy you can grant. The one enables the other.” The biggest benefit of this approach is it allows the product owners to synchronize the priorities of the business with all the teams at the same time. In the hypothetical case that there is a change in the primary objective of the teams, we will be able to adapt easily. For me, having all the ceremonies on the same day allows me to be focused on other things during the rest of the Sprint always keeping in mind that this day is exclusively for those ceremonies and creation of reports.

Use meetings for their intended purpose and respect time boxes

Besides holding all the Scrum ceremonies on the same date, it is also crucial to respect the duration and intended use of all the meetings. I own the responsibility for keeping the meetings running on time and maintaining the focus on the designated topic. I know that many people have experienced daily stand up meetings that take 40 minutes and wander off-topic to things only relevant to a small portion of the team. These inefficiencies are something that I always avoid; our daily Scrum meetings rarely take the recommended 15 minutes instead, they are often much shorter. If there is an urgent topic that must be discussed or clarified, I invite only those involved to stay after the end of the daily meeting. The rest of the team can drop-off and be focused on their work. 

Identify leaders and entrust them with decision making when possible

Every Agile team is typically composed of developers, quality assurance engineers, UI/UX designers, dev-ops, etc. Recognize the leaders on each of your teams. Since you will have several teams with many members and will receive multiple requests from each of the teams, it is powerful to delegate some decision making to the trusted team leaders. If an issue cannot be resolved by those leaders, you can take part in the decision making.

Avoid micromanagement and ensure your team members are comfortable asking for help

In my opinion, micromanagement is a terrible practice. Regardless if the team is an Agile team or not, micromanagement injects a lack of motivation among the collaborators. It also adds a distraction from essential work to be done. For you, as a leader, micromanagement will add unnecessary and detrimental items to your to-do list. Instead, stick to the best practices derived from Agile methodologies—be open to team members reaching out to you whenever they need assistance. 

Build a solid team composition with clear expectations

I have to be honest; I have a bunch of rockstars on my teams. It makes everything so much easier when you can trust any team member. When my team says they will be delivering something on a specific date, it happens that way unless there are extenuating circumstances. If something unexpected does arise, there is always good communication from them in advance. With the forewarning that something is not working as expected, I can manage the risk easily. Of course, this is something that does not happen immediately after starting a new project. To build solid team composition you must work to get to know each other, make sure expectations are clear, and have regular communication. 

Leading teams is not an easy task but applying the strategies described above can help you to provide guidance to each team member in order to achieve a key result or objective. Almost every soft skill requires practice and can be continuously improved, it will reinforce your leadership and direction in the company while you combine the best project management skills. The team will show their appreciation by being heard and recognized. The success of each project is affected positively when each member is empowered and envisioned with the goal. Becoming a team leader is a process where you have to take advantage of the different skills and personalities to face challenges and gain trust.


  1. “Agile Release Train – Scaled Agile Framework.” 28 Oct. 2018, Accessed 9 Jul. 2019.


New call-to-action