Agility in Large Teams

In the two and a half years that I have been at Thoughtworks, I have been part of three different projects and have worked out of three locations. My current project team is the biggest I have ever worked with. We are working on the development of a Global Web Transformation Platform for the website of one of the leading manufacturers of electronic products in the World.

When I joined this project in Pune in August 2013, it was a team of around 40 people with 5 sub teams. I was a part of the smallest sub team, with 4 people . The common belief is that a big team has a set procedure, which everyone follows - the way of working, routine, pace of meetings, including what the team does for fun. However, the team that I am currently on disproves that theory completely. I think this team is a very good example of an Agile team in the true sense. As the saying goes: “Don’t do Agile. Be Agile.”

These are a few of my observations from being a part of a large team:

#Changing Team Structures: From the beginning, we experimented with different team structures to optimize time for stand-up, pair rotations, work planning, creating context boundaries etc. Initially we had 5 sub teams split by type of work. We eventually merged into one big team, which had its own pros and cons. Then we divided the single team into 3 sub teams with the aim to improve pair rotation within sub teams. We tried to make sure that almost everyone had some context around the functionalities within their sub team. This eventually led to people signing up for varied stories. But a few months ago, the team had a ramp down, after which we again merged into one big team. We still continue with the one-team structure. We  faced many challenges initially - not having pair rotations led to working in silos, increased duration of stand-up etc. We addressed these pain points during the retrospective sessions after every iteration, which I have detailed in the points to follow.

#Managing the Standup: With the changing team structure, the time for the stand-up also varied a lot. When we had 5 sub-teams, we had one large stand-up with only team-level updates, and separate sub-team stand-up for individual updates so that we could optimize the stand-up time. Very often, we had separate Developers, QA and BA huddles for sub-team collaboration. After the ramp down, we again merged into one big team. But this time we would start with a walk-the-wall session and then pass around the token for individual updates. With the kind of team structure we had, it made sense for us to walk-the-wall, so that everyone could get high level updates of features that we were working on. This activity really helped everyone in deciding what feature/functionality they wanted to work on next. Also, if anyone faced any issue regarding their feature, they could describe the issue and get someone signed up with them for guidance.  So far, this approach has been working quite well for us.

#The One with Meetings: Being a part of such a large team which involves so many sub-teams and stakeholders, brings in a communication overload. Meetings are integral - being part of Client meetings and technical sessions is important because it always gives better context. But sometimes, depending upon the subject of discussion, it is necessary to take a call on whether it is valuable to you or not. For example, a certain person might not be interested in the staffing discussions, but interested in discussing upcoming features and so on.

#Email Bombardment: Apart from meetings, another common form of communication is Email. Often, there are vendors involved in the project with whom we collaborate. Numerous emails are exchanged daily and it becomes difficult to keep up. The real challenge is to decide which Emails to follow and which ones to filter out. Thankfully, I have been able to develop this skill (well almost!). I follow Emails and reply those which are sent directly to me. Nevertheless, I glance through all the Emails that are sent to the team, so that I can provide my inputs when required. In addition, I have created categories to filter out Emails that can be referred to on a need basis.

#Large Contextual Silos: This project has been running for more than 2 years now. For a new joinee in the project, it becomes a tedious job to understand its full context. Realistically, it is close to impossible for a person to have complete context about everything. You have to depend on another teammate for one thing or the other. In our team, we have created a series of on-boarding videos on the domain, architecture, team members and code. These have been very helpful for quicker context sharing with new joinees.

#Huddles: With many Developers, QAs and BAs in the team, there’s always someone for you to seek help from. If you are stuck with something and can’t decide on what to do next, you call for a huddle. These huddles are very effective to get quick feedback on the approach you take to solve a problem that you are facing.

#Souvenirs: In Thoughtworks, every team creates a project t-shirt for themselves as their project souvenirs. We did too. After our first go-live, we created a hoodie which was appreciated by everyone. After the second release, we created a t-shirt. Finally, after the thrid release, we made another hoodie. It was a lot of fun!

#Big Fat Team Outings: When you work with a large team such as this, you get a big budget for team outings. We have been on some great ones. We went to the movies and we went for meals. We also arranged short weekend trips to places around Pune.

Apart from these learnings, a large team with its ever changing dynamics, trains you to understand a situation better, analyse it completely and act accordingly. This enhances your analytical and problem solving skills. I have gained much more than just technical knowledge while working on this team; I have made some close friends too. We have developed some fun traditions that we follow and often laugh about. This team has been a part of my life for more than a year now and I find it hard to describe how much I enjoy being a part of it. :)