Scaling Agile in Large Dependent Teams Setups

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.