Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
I recently came across Carl Erickson’s ‘small teams are dramatically more efficient than large teams‘ blog post which reminded me of something which my colleague Ashok suggested as a useful way for determining team size – the application footprint.
As I understand it the application footprint is applicable for an application at a given point in time and determines how many parallel tasks/streams of work we have.
In the case of the project that I’m currently working on there are 3 separate components which need to interact with each other via an API but otherwise are independent.
We can therefore have 3 pairs working – one on each component – and won’t have to worry about them stepping on each other’s toes.
One interesting thing about the application footprint is that it doesn’t stay the same size all the time.
More often than not once a team has gained trust by getting a release out the product owner will start prioritising more independent features which don’t necessarily overlap.
At this stage it might not be such a bad idea to add people to the team if we want to try and finish more quickly.
If we’re already at the point where we have the same number of pairs as parallel pieces of work then adding people is going to be problematic because we’ll struggle to find work for everyone to do.
Stories in the same stream will have dependencies on each other and although it’s theoretically possible to start on something which has a dependency, the likelihood of having to rework it is higher.
One way to get around that problem if we decide that we don’t want to reduce our team size is to have a pair assigned to working on bugs, cross functional requirements such as performance testing/tuning or doing some technical analysis on upcoming stories.
It’s easy enough to remember all this when you’re starting out building an application but I think it’s something that we need to keep in mind so that if there’s pressure to add people to ‘go faster’ then we can determine if that will actually be the case.
As an aside
Obviously there are times when we decide that we’re happy to put more people on a team than it’s footprint might suggest in order to get an overall gain.
For example with 5 pairs we may finish 50 points in a week but if we increase to 10 pairs then perhaps we now get 60 points.
We’ve nearly halved the efficiency of each pair but overall we’ve got a marginal gain which sometimes makes sense. We also need to be aware of the collective unresponsibility that we might introduce by doing this.
Photo courtesy of farlane
Opinions expressed by DZone contributors are their own.