Mo’ People, Mo’ Problems
Whether you roll with Agile, Waterfall, or something in-between, there’s something weird going on. A big reason why the folks came together at Snowbird back in the day was to figure out better ways to build software. You’ve know the deal: quicker, higher quality, all around mo’ better. With Scrum, this is set into motion with the idea that smaller teams function better than larger ones. But the weird thing is that some folks are under the misconception that more work gets done by throwing mo’ people at the problem.
They forget the part about breaking work down into smaller bits. Before they took a stab at “going Agile,” they probably released legions of code to production every six months, or even longer. Struggling to understand this strange, new way of development, the tendency is to try, and cram six months worth of development into a single sprint. What you end up with is Waterfall, but in 2-week increments.
This Herculean effort ends with predictable results: at any given time there’s too many things in progress, work isn’t completed when the end of each sprint rolls around, and it regularly flows into the next one. I sat smack-dab in the middle of this trend, when the company where I previously worked took on a small army of contractors, confident that the influx of new, cheap resources would guarantee increased throughput. Guess how that ended? It’s like how Scrum Master Notorious B.I.G. said:
“I don’t know what they want from me. It’s like the more people we come across, the more problems we see.”
In a recent department meeting I attended, a C-level executive referenced Fred Brooks’ 1975 joint, The Mythical Man-Month. Someone had thrown out “We need more resources,” and he came back with Brooks’ Law. He asked if anyone knew the exceptions to the law, and how when adding people isn’t a viable option, calling out the other “levers” that can be pulled to manage the issue: scope, time, and money — which is a project management model called the Triple Constraint.
Even Brooks says his law is an oversimplification, but here’s the thing. When transitioning to an Agile way of doing things, and you’re having issues hitting the mark, the problem generally isn’t the size of your Scrum team(s). It’s not a people problem, it’s a scope problem. In this context, Brooks’ Law becomes irrelevant, and adding mo’ people isn’t necessarily gonna fix a damn thing.
Back in the day, when Pandora hit 70-million subscribers, they had less than 40 developers. With that in your back pocket, why do you think teams with 5, 10, or upwards of 20 members struggle to finish what they started in a sprint? Whatever the size, teams can’t build all the things in 2 weeks, yet I’ve heard people say “I need everything outlined in this feature, which is my MVP.”
The truth is that loads of people struggle with MVP. Leon Tranter mentions the scope creep bogeyman in How to manage scope creep in Agile/Scrum, but keep Pandora in the back of your head. You gotta be ruthless, and disciplined about priority. Take a gigantic feature, and with the help of your friendly neighborhood development team, break it down into something that can realistically be delivered in a sprint, or less.
Constantly look at what’s getting completed each sprint, and based on progress, adjust the forecast of when the entire feature can be completed. While you’re at it, peep Rolling Wave Planning, but please don’t reach for the Work Breakdown Structure.
So please stop begging developers to work 60+ hours a week, and keep the idea of throwing mo’ people at the problem out of your head.