During the latest months, I’ve been asked to move from a small agile team to a large one, why? what changes should I cope with? what obstacles to tackle and what kind of achievements we accomplished? here are the experience story and the learned lessons

Small Agile team​

I've been part of a small agile team of 4 developers, tech-lead, UX designer, Scrum master and a Product owner. Working with scrum method, I do believe that this team size was just perfect as the communication is too smoothly and decision making is quick and effective. We developers were using the git flow branching strategy. A new branch is created for each user story, commit added, pull request created and reviewed then merged into the master. Product owner manage easily his backlog. The scrum master scheduled perfectly our scrum sessions and these one were gainful in term of business understanding and story telling. Thanks to the great work of our UX/UI design integrating the UI and implementing the user experience is definitely optimal thanks to sketch software.

The team size was a key element to a successful journey, providing a great added value at the end of each sprint while delivering high-quality software with security standards-compliant.

Communication and collaboration

When is come to working together and collaborating with a team, communication is a key factor toward success. While this is easy for a small team as we are often setting around the same table or in the same open space we communicate orally and directly trying always to avoid emails and chat as much as we can, but for sure without omitting to give each one its private space and time to concentrate on his tasks with no disturbs. In the other hand and once the team getting larger we first obstacles we start to face is how to communicate and exchange, even harder for taking a decision. Another point is managing meetings which means to manege finding rooms especially as we are working in a co-working building then as we have to take into consideration each one is calendar. Now we are in the meeting room with more than 12 team-mates it took longer than expected, deviation and rarely we end up with a defined actions list assigned people.

I believe either we are a small or a large team there are the right tools and ways to communicate, We need just to avoid applying the ones that work fine for a small team in the context of a large team and vice versa.

Support and expertise

One of the greatest points when you are part of a small team, is that you know each member is scope of expertise which is very useful and effective when it comes to coordinate whether to change a piece of code, to integrate a new technology or document a feature. Unfortunately this advantage disappears along the way a team begins to extend and we start to be distributed which affects our knowledge about expertise mapping in the project and for sure consume more time to find the right source to support you.

I refer to Conway's law stating about organization structure footprint on their production:

Organizations which design systems ... are constrained to produce designs which are copies of the comminication structures of these organizations. "Melvin Conway"

In our organization we understood this quickly and thanks to our agile coach we reorganize our teams and introduced some practices to continue delivering added value feature continuously.

Single Point of Knowledge​

As our team begin to grow and having many members than needed in an agile model, I observed in the lake of coordination, close collaboration, and effective communication, new single points of knowledge taking place in our organization as some people with or without attention monopolize and hold in their corner some specific knowledge or expertise which impacts the pace of productivity, innovation, and rotation. Contrarily to the case of a small team where the knowledge and responsibilities are well shared and all members have almost the same level of knowledge about the project which avoids the 'indispensable member' obstacle and lead to transparent and rapid rotation and delivery.

Team representative and interface​

When I was part of a small team there was a member who keeps the team informed, knows the organization’s culture, and promotes best practices that make our entity inspiring. Often this role appears naturally cause the person playing it holds some qualities that help him representing the team, interfacing with management contrarily in the context of the old school team, a project manager take this responsibility. But can we have many representatives (Leaders) in the team? In my point of view, YES as each member has a different style therefore we can boost the team’s productivity and creativity. Shared leadership led also to reduce responsibilities stress, thrive solidarity. For the company we observed many advantages once we made the move to this model:

• Share the the bigger picture with everyone.
• give the company more options.
• increase in decision making transparency.

Finally, the question is can this model succeed with a large team? From my experience, this can be a huge challenge for the management but also for immature teams who can considerably slow down the decision making.

I’ve been part of different teams small and large and I believe that adopting the right management style and establishing a transparent and honest relationship whether between team members or between teams and the management should always gain the upper hand.

Being the representative of your team is talking about your shared values and practices, defending your team's decisions and choices. But in any case shouldn't be a position that we take over.