A tweet by the incomparable @afox98 started my thinking processes. In my long tenure in Product Management, there have been times when there was a sense of urgency in completing a project and get a product out the door. To spur this along, at times, more engineers and scientists have been thrown at a project to “accelerate” results. But universally, this has not yielded faster progress, and instead has caused a rise in senior management discontent with the product management/product team concept.
The Dude firmly believes that projects and project teams that are effective have an optimal size. Too few resources and the team struggles to keep momentum. Too many resources, and team members spend too much time waiting for someone else’s work to be complete, and progress is inconsistent. The difficulty is, that to management, scaling a project up means you get more output. This works when building cars. Adding a production line will incrementally, and predictably increase the output of automobiles.
But this short-sighted view fails to take into account that production != development. Let’s stick with automobiles. From what I have read, a new car design takes 5 years from concept to production ready. There are dozens of teams involved. Drivetrain, powerplant, body, electronics and controls, interior design, exterior design, and many others. These teams all have a portion of the project in their purview. These teams are connected, but operate somewhat autonomously, but are coordinated by the project management team, so that they all deliver their parts at the right time.
The answer to project velocity is in the above example. A big project is broken into smaller teams. The smaller teams are optimized with technical and design members (think: Developers and QA) working towards a specific goal.
However, in the Software world, or technology device world, the tendency is to make one giant product team. But every team like this I have been associated with (mostly HW + SW and devices), there is tension between the factions, and lots of blame on delays laid on the “other side”. Software is already waiting for hardware. Hardware is waiting for software. A self-reinforcing feedback loop gets initiated, and deadlines, and anticipated completion dates get pushed.
And management’s response it to throw more people into the mix. Making a bigger team, but in every case, the ‘done’ date is not accelerated. You just have more people waiting for others to complete their efforts.
Agile is part of the answer. I won’t go into details, but the iterative processes, and the sprint focus helps significantly. But the danger still exists to build a large team. Resist this temptation. 8-10 developers and QA members (the mix varies depending on how much test automation you can do) seems right in my experience. Break your project into logical sub projects, and staff them appropriately. If you have a huge project, it is likely that you will have logical lines to break a project into. If you want to accelerate progress, add a team, and split the scope. Don’t just double down the staff on the project.
