IMHO it's not a good idea to directly and immediately apply a team's gains from its DevOps transformation into scaling the team down. At best you'll lose just the team's motivation to do any such improvement in the future. But most likely you'll lose most/all the talent in that team.
Instead:
- allow the team to appreciate the benefits of the difficult transformation they went through, so that they spread the word to your other teams that will have to go through (or are already struggling with) the transformation
- focus on delivering better quality products/services, faster - with the same team - this is now possible due to the transformation.
- in many cases your business will pick up speed because of the transformation - soon you'll more likely need to hire people - IMHO it's better to use the experience of the ones you already have rather than educating new hires
- allow voluntary attrition to work for you and get the effective downscaling down the road.
But generally the DevOps transformations tend to not happen fast enough to allow for the above choices :)
Now onto scaling up/out.
Ideally the DevOps transformation should have greatly increased the predictability of your sw development and delivery process. You should be able to tell with a great degree of precision you existing team's capacity: how much sw/services of a certain quality can your current team get done in a certain amount of time.
When you need more stuff done, or done better/faster than the current team's capacity you need to scale the team up/out. The exact details come from whatever process/methodology you use for your day-to-day activities, probably some agile variant (see also Does my organization need adopt Agile Soft. Dev. before adopting DevOps?)
How - apparently easy: hire more people to handle the overflowing activities. If you're worried about how fast you can get them onboard and actually handling that overflow work at the expected rates: start hiring earlier, based on projections.
The reality can, however, a bit more difficult than that. Scaling a software product/service or the development process and tools supporting it is not necessarily straight-forward, even for a DevOps-empowered organisation.
One of my favourite examples is the weakest DevOps link when it comes to scalability: Continuous Integration. If the CI build fails there can be no Delivery/Deployment (kinda undermining the "continuous" term in the CD context).
Just because a certain team is happily using CI with decent results it doesn't mean the same will happen if the team size doubles. Nope, the results could be devastating - the delivery process can grind down to a halt (in extreme cases). I'm trying to explain this in Congestion in Traditional CI Systems (disclaimer: I'm the founder of the company owning the referenced page and offering a solution to this problem).
Another example could be, for example, the version control system (VCS) being used: as the software being stored into a repository evolves so does its change history, pushing the limits of the VCS system, sometimes beyond acceptable performance levels. Switching to a more scalable VCS system or splitting the codebase into multiple repositories could be an approach to address the problem.
But evolving the development processes and tooling supporting them alongside the evolution of the software products/services being delivered are fundamentally just what a mature DevOps team does. They just need to also be taken into consideration when in the team's scaling up/out strategy.
With that in mind, the how can be, indeed, reduced to just increasing the team size to cover the additional amount of work necessary for execution of the above-mentioned strategy.
