Several people on LinkedIn commented on my post, Want Better and Faster Results? Increase Team Size and Reduce WIP. They wondered if adding more people to a small team would violate Brooks' Law.
As with all good questions, the answer is “It depends.” It depends on how your lifecycle manages feedback loops and learning, how collaborative the team is, and how much WIP the team has.
Each Lifecycle Manages Feedback Loops Differently
Brooks wrote the original version of The Mythical Man-Month in 1975, based on the 1960s IBM 360 project. Royce didn't write his paper shredding the idea of a waterfall approach until 1987. So many of the rules/suggestions/laws in The Mythical Man-Month refer to the lessons Brooks learned in the 1960s.
The first is that Brooks strongly suggested the idea of a “surgical team”. That hierarchical team was a feature- or product-based team. The quote I found most useful was on p. 35 (in the anniversary edition):
“The team just defined meets the desiderata in several ways. Ten people, seven of them professionals, are at work on the problem, but the system is the product of one mind–or at most two, acting uno animo.”
While that might not be the kind of collaborative team I prefer, the surgical team is a collaborative, cross-functional feature team. (Uno animo means “unanimously.)
Brooks also said on p. 37:
“To make that job manageable, a sharp distinction must be made between architecture and implementation, and the system architect must confine himself scrupulously to architecture.”
These ideas can work under these conditions:
- The team has no multitasking with other teams, other projects, or other work. Everyone stays on the team at all times. That allows a team response to late feedback loops.
- The architect collaborates with the other architects, so the architecture is coherent across the product. (Yes, the premise of my Agile and Lean Program Management book.) That's the reason for the break between architecture and implementation.
- The tester is involved from the start of the project.
I have never seen those three conditions in any non-agile project, but that could be my experience and not universal.
Let me start with the idea of feedback loops.
Serial Lifecycles Often Have Unplanned Feedback Loops
Feedback loops indicate when the team learns. That's why there's feedback. If you read my Lifecycles series, you saw many possible unplanned feedback loops. This image is from Part 1, the serial lifecycles.
The reason the requirements “phase” lasts so long is that the team continues to learn through Analysis, Design, Code, and Integration. Notice the reduction in test time in the middle of the three images.
But the absolute worst time to learn is during the test phase. The team realizes something during the testing that creates a need to change the requirements. That change cascades down through Analysis, Design, Code, etc.
What does management choose to do? Too often, management chooses to stop the testing and release anyway. If so, the team releases a product with an unknown number of problems. The post-release Cost to Fix a Defect goes through the roof. Worse, people start to multitask because they're supposed to be “done” with this project and onto the next.
The next project starts with scarcity, and that's when I've added more people to a late project, and we did not lose time.
When You Might Add More People to a Late Project
Imagine Previous-Release took longer than expected. The customers yell at Support. So management says to the team, “Start on New-Release, even though you're not quite done with Previous-Release.”
I described that experience in More on Creating Faster Cheaper Projects. (I added the image here in case you don't want to read that post right now.) That's why many people were interested in the ratio of developers to testers back then.
This image reflects just one of my experiences starting a project without the necessary skills and capabilities. (All the other graphs look much worse.)
The architect started in January and worked alone until March. We've already violated Brooks' surgical team premise. We didn't get the number of people on the project until June, and we only had one tester. Now, the tester was 6 months behind. But we had more problems:
- The team did not collaborate, so the WIP was very high.
- This team started off with a serial lifecycle, so they didn't even plan to have a demo until about September or so. That's when they thought the project would be done, and most of the development staff could leave to start the next project.
- They had crazy-high WIP because each person started their own tasks, not even their own feature. They implemented across the architecture, not through it.
This team had no idea where they were, even though they knew exactly how much money they'd spent.
I chose to add more testers and writers and increase the team's collaboration so we could see a monthly demo. At the time, I did not realize I reduced the WIP.
Add More of the Scarce People and Collaborate
The longer a project takes, the more the requirements change. The later the feedback loops, the longer the project takes. Each longer feedback loop means the team learns slower. (See When Requirements Spawn Requirements.) Worse, the longer the feedback loop, the higher the WIP.
The more the requirements change, the more pressure people feel to start more work. But Little's Law always wins, so the cycle time gets longer, the throughput gets lower, and the WIP increases.
Because I'd measured and observed a ton about software projects before I consulted, I knew that we could stabilize the project if we knew where the defects were and if we could document that knowledge. Knowing offered us more choices than to just extend the project.
That strategy worked in many more projects from the late 80s through the mid-2000s. Sometimes, I was lucky enough to add those people in the middle of the project, but more often, I added them at the end.
As the project manager, I insisted on collaboration. At a minimum, no one could check in anything without someone else's review. I asked people to swarm (because I didn't know about mobbing and pairing experiences up until then were horrible.)
I was unconsciously competent. My actions increased the team learning, reduced the WIP, and increased the throughput. While we rarely shipped everything management wanted, we could ship at some not-too-distant date. That was much better than shipping because the lead engineer's wife threatened divorce.
WIP Matters
WIP isn't the only thing that matters, but high WIP has such terrible side effects: low throughput, high cycle time, increased WIP. Worse, everyone feels pressure to start more, which is the worst possible decision.
If we want larger teams to finish more work faster, those teams need to collaborate. That's the way to reduce WIP and increase throughput. We can “surgically” insert people on teams if those people help the team learn faster. (See Manage It! for more details.) We can't just add people and have anyone work alone. At a minimum, people need to pair/buddy. Even better is when the team mobs, to keep their current WIP low.
Brooks was right for a serial lifecycle. But he wrote about a 1960s experience. We know a lot more about lifecycles, team-based collaboration, and have access to many more tools. Teams no longer need an administrator, a clerk, or a language person. Brooks' 10-person team had only 7 technical people on it.
So yes. If we have a collaborative team that manages its WIP, we can add more people, depending on the lifecycle. The earlier the better. But even if we add people at the end, those people can increase our knowledge, which means we can make better decisions.
See Want Better and Faster Results? Increase Team Size and Reduce WIP for the prompt for this post.