Because developer hours are always our most limited resource, project monitoring and capacity planning are some of our most important management aspects. Foreach has 25 full-time developers at the moment, a combination of Java devs, .NET devs, and front-enders. At any given time, a developer is working on two different projects on average. As such, efficient planning has become a complex and time-consuming effort. Done well, it greatly increases productivity. Done badly, everybody gets confused, mistakes are made and efficiency plummets.
When Foreach started out, there was much less need for this amount of planning, because we simply had one team per project and very little communication between teams. While this was tenable from a certain perspective - everybody was working efficiently within the project - a lot of knowledge and skill was wasted, as similar solutions were developed in parallel without other teams ever knowing.
As we’ve grown and taken on more and more varied projects, however, there was no escaping professionalizing our capacity planning, man-hours being the most limiting factor in our growth. We tried using complex (and expensive) planning tools at first, such as Office 365 and other Gantt chart tools, but these quickly turned out to be too complex for our needs. The time we gained simply couldn’t justify the time required to keep them up to date. So we went back to basics and created a system using Google Drive and a lot of communication.
On the one hand, we create a short-term planning every two weeks. The first version of this planning is the responsibility of the project owner and is based on the conversations with the teams and the clients. The project owners team then comes together to create the planning for the next two weeks. While this method of planning is rather time-intensive, a meeting with six people every two weeks taking about an hour and a half, it has the added benefits of creating broad lanes of communication between the different projects, and requiring every project owner to really own their projects, to optimize them as much as possible and to have their eyes not just on the immediate future, but on the entire flow of the project.
On the other hand, we make quarterly plannings, anticipating the changing needs of each project and predicting the impact of (possible) new projects. This allows for proactive recruitment and (hopefully) heading off brewing troubles before they can manifest. By looking beyond the immediate future, we can more easily identify and anticipate our situation, rather than having to react to unforeseen happenings.
Nonetheless, the unforeseen aspects do remain the biggest hurdle. Ballooning needs can thoroughly shake up any planning, requiring shifts in working schedules that ripple through your entire company. But even in those instances do we attempt limited and focused intervention. While in theory, any developer can work on any team, there needs to be sufficient consistency within a team for it to be able to work as a team. From the perspective of the developer, it’s not a pleasant long-term position to always be the fireman, getting shifted around wherever there is a fire that needs to be put out.
The system we have now is still a work in progress, that gets refined with every meeting. But as we don’t expect to be drowning in talented developers anytime soon (check out our recruitment blog post for more information), we’ll continue to plan for the optimal deployment of all the talented developers we do have. And for that, communication is key, which isn't a groundbreaking insight, but putting it into practice turns out to be a complex organizational hurdle.