One of the ideas around DevOps is that things are done quickly. In order to do things quickly the size the change needs to be small and intuitively that makes a lot of sense. The smaller the change the faster it can be implemented.
Frederick P. Brooks Jr., in his book The Mythical Man-Month, talks about how developers are poor at estimating and that one of the reasons is that the amount of work to do a single item goes up the more communication is involved. So, if one person takes twelve months to do a project the typical Project Manager (sorry, painting you as the bad guys right now) would assume that if you assigned two people you could get it done in six months. And if you assigned six people you would get it done in two months.
And therein lies the problem. The more people, the more coordination and the more coordination the more communication. There is no definitive formula to use as the coordination and communication factors are dependent upon how inter-related the work is between people. For instance, if that twelve months of work was actually six discrete items with no relationships or dependencies between work items then you very well may get it down in two months. But, as is the case with most software written today, if the twelve months of work is actually dozens of items, all inter-related, then there is no way it can be done in two months. It may take three or four months meaning that the total effort is fifty to one hundred percent higher because the work was split amongst people.
Which is why the worst thing you can do when a project is late is to add more people to the project. You’re going to make it even later. You need to do what Lean Manufacturing has taught IT: create smaller batches of discrete work. We do that instinctively when we have a project at home, we break it up into smaller pieces and work on one piece at a time on the weekends until everything is done. But in IT? We’re too good to learn from our parents so we struggle with adding people to a late project and discovering that we are just as late as we were originally going to be … we’ve just added a lot to the cost.
This is why Amazon uses something they call the “two-pizza team”. If two pizzas is not enough to feed the team then the team is too large. If the team was my family we’d be looking at a team size of six, which, coincidentally, falls in the 5 – 8 range that is recommended. For decades this has been considered the optimal size of a team. Large enough to get substantial work done, but small enough so that everyone knows who is accountable for what pieces of the overall system.
Does this cause problems for Project Managers? Yes and no. Yes, in that a significant endeavour may need to be divided amongst multiple teams, but, No, because things should actually run more smoothly than expected. Build applications the same way you do house repairs: a little bit at a time until everything is done. Small teams releasing small pieces of work that can be assembled into something much bigger.