Over the last year, my small development team has grown from only a few developers to a current count of eight, and it could soon grow even further. A colleague and I have been working as the tech leads together on the project. However, we both lacked experience working on large development teams, let alone leading them. It goes without saying that you can’t work exactly the same way with a team of eight developers as you can with just a few. We struggled at first to determine exactly what we should change about our team’s practices to enable ourselves and our team to do our best work.
Early on, we were staring down the prospect of our team suddenly doubling in size. After a while of working in this large team, though, we’ve gradually adjusted and changed our approach to running a project. We have now settled into a more comfortable routine. Below I list a few of the practices we’ve implemented to help the team work together effectively. It’s not comprehensive, and we’re always working to improve how we do things, but these practices in particular have stood out as being worth mentioning.
1. We hold weekly check-ins.
There’s nothing revolutionary about a weekly meeting, but I found an important addition to everyone’s schedules on my team. We do an end-of-the-week review session where the dev team meets up and everyone shares information about what we’ve been working on or asks one another questions.
Through standup, we know what everyone is doing day to day. But, with so many developers, sometimes there’s a need to inform the team of larger changes that only one or two people may have worked on. We also use the time to make suggestions to each other about potential improvements to the project. Since every team member must be able to work on any given part of the project, this meeting has worked out great. We can keep each other in the loop when team members haven’t worked on a particular feature in a while.
2. Everybody is responsible for code reviews.
Similarly to our weekly check-ins, making everybody responsible for doing code reviews has been valuable. It’s a way for everybody to stay informed about what is changing in the project without actively working on every part of it. It also gives junior developers valuable experience as they participate in the acceptance of code to the codebase. Ultimately, the tech leads are responsible for what gets approved, but we’ve had success evolving this part of the project into something more collaborative across the entire team.
3. We have a dedicated floating developer.
As our team grew, my fellow tech lead and I found ourselves stretched pretty thin. We were carrying feature stories, assisting developers with emerging problems, onboarding new team members, and participating in client meetings. At first, we didn’t know how to handle it and found ourselves slowing the team down. In particular, that was because of the feature work we were trying to do on top of our other responsibilities. This ended up helping us realize that, given the team size, we could definitely have the same team velocity even if we stopped carrying stories.
So, we adjusted our approach to the project to stop carrying features regularly. Instead, we allowed ourselves to be readily available for pairing with the other developers. We filled in the gaps with backlog grooming, investigative work, and other high-level project strategies. This was especially productive for our junior team members, giving them the opportunity to work independently while knowing that the leads were available to jump in and unblock work if any problems arose. As time has gone on, the team has adjusted well to the work ahead of us. There’s less need for pulling us in, which has allowed us to get back into feature work ourselves, too.
4. We emphasize collaborative tools.
The emphasis on collaborative tools is the ingredient that has enabled the previous practices I mentioned. Three come to mind in particular.
Most useful has been the remote pairing tool Tuple, which has enabled us to do some very quick pairing when remote, with quicker setup than Zoom, good screen sharing quality, and markup tools we’ve found better than similar tools like Slack huddles. The drop-in drop-out nature of Tuple also has made it easy to join each other’s pairing sessions when necessary, which makes dropping in for some quick help very easy.
We’ve also tried to take advantage of Postman, which lets us share important API calls the team makes on a regular basis, as well as more specific calls such as a sequence of requests for demo purposes.
Last is a simple feature of Slack, user groups. These have enabled us to easily ping the dev team without tagging many names at once, or using “@here” and additionally pinging the non-dev members of our team unnecessarily. The user group makes it easier for us to have discussions asynchronously, without restricting them to direct messages where other team members can’t keep up with potentially relevant conversations. Use it wisely so you’re not constantly pinging each other with notifications. But, as a team, we’ve found a good balance with using it to ensure when we see the notification. We don’t just ignore it due to a high volume.
My team definitely has plenty of work left to do to improve our practices and the way we collaborate. But, I think the practices I’ve listed above can be a great start for any small development team as they grow into a larger one.