Reducing staff leads to higher productivity – proof for Brooks’ law?

Recently, my teamlead agile methods pointed me to an interesting corelation. After a discussion we concluded with a really mind-boggling observation. A settled organization facing change will increase productivity when reducing staff headcount – in other words: “Reducing staff leads to higher productivity”.

Bang! But let me explain. For software development tracking and planing purpose we use JIRA – so we’re able to track the amount of created and closed software development related tasks quite easily. The headcount in software development, product management and UX/design can be obtained easily by – counting (we actually asked our HR department for support).

In our case we ended with this curve – impressively proving Brooks’s law.

Brooks Law in action

The graph shows a period from June 2013 (left) to July 2014 (right) and focuses only on one of our products at the time.

Green shows the number of software developers working on the product. Purple shows the number of product and UX/design people involved. The two curves are declining.

Red shows the amount of releases done in the period.The curve is trending towards a stable, flat curve.

Blue shows the amount of tickets closed and turquoise the amount of bugs closed. The two curves are decreasing trending towards a way higher plateau.

What happened? In June 2013 time frame we had a whole architecture team and quite some software developers organized in three teams working on our product. Around this point in time uncertainty hit the organization due to rumors of to-be-expected acquisition of our whole company. Uncertainty translates often to people leaving the organization. This can clearly be seen in the middle of the graphic. Surprisingly, the curves associated to work results don’t decline – as one would expect – but decrease even. So, productivity of the remaining staff increased! The most right date in the graph is July 2014 and reflects an organization which has one product team and one support team left. The architecture team disappeared completely, the team is ways lighter equipped with people.

What might we learn? Brooks’ law indicates that adding people to a project doesn’t automatically make the overall project finish faster. It might even end in a longer project run time. We’ve seen that removing people might result in better productivity. We think the fact of removing whole teams dedicated to special topics (in our case: the architecture team) helped to increase productivity in two ways. First, the responsibility of architecture decisions was pushed back into the teams and dead-lock situations where person A waits for a decision from person B just disappeared. Second, the time needed to communicate, agree and disagree simply vanished. Decisions had to be taken and nobody needed to be asked.

Is this a general pattern? I personally think this effect does only appear for a certain period of time. The drawback of such leaner organizations is obviously the lack of work on technical debt and architecture drawbacks. People in such situation focus on the obvious and postpone work on maintenance tasks for later. For me, it is definitely an observation I’d like to share with you. Perhaps you have similar experience? If so, please let me know.

Is there really a relation between the number of staff members and the productivity? Where is the limit? How can one push the limit?

What is SCRUM?

What is SCRUM?

… or better said – what is it NOT?

When we introduced SCRUM we simply removed all project management structures and replaced them with agile – means SCRUM – process templates. We renamed “Project Manager” to “Scrum Master” and “Product Manager” to “Product Owner”. From this day on we were entirely agile. This worked fine for the – initial two sprints. User stories were small enough to fill up the sprint, they weren’t as complex to produce headache, and the overall spirit was positive and optimistic.

So, the bigger stories were produced by our product owners. One user story spawning multiple sprints? No problem at all. We started to work “agile” and followed the basic rules of waterfall (plan, build, run) forgetting all the nice agile ideals. Where we ended actually? Chaos and anarchism – no joke.


What lessons we learned – in a retrospective view?

  • SCRUM is a software development tool. It doesn’t free you from all the project management pain. Now, in our organization – we still have technical project managers looking after the huge topics or those needing external support. They get all the different departments organized and look after well-needed input from those departments – allowing the product owners to focus on their part of the game – filling the backlog and controling the product definition. We sorted out the mistake of renaming roles from the waterfal world into agile roles. Now, we have a thorough understanding of what the different roles in SCRUM mean – and what they have to focus on. And, more important where SCRUM roles end and you still need assisting roles.
  • SCRUM doesn’t replace your organization, roles and hierarchies at all – it allows a different view angle on these topics and highlight the product issues.

P.S.: If you were looking for a SCRUM introduction … Try these sources …