It is a natural outcome that development operations (DevOps) and IT will build out infrastructure to just meet the needs of the organization.  This is a reasonable approach, as investment in capacity and slack is a difficult argument to make as IT organizations do their best just to keep up.  When organizations embrace agile and lean methods to improve their practices, they will quickly realize the infrastructure must expand to support new levels of productivity, collaboration, automation, and tooling.  If not addressed prior to implementing changes, the impediment can stifle early gains and lead to muted successes.  This drag on productivity can have significant impact on the overall change initiative as management and team members alike tire of implementing change only to see modest results.

In 2009, I had the opportunity to work with Jeff Sutherland as a part of an all-at-once Scrum adoption while at Pegasystems.  A transition to Scrum and significant expansion of the development team quickly led to us ‘Hitting the Wall’, as the organization quickly outpaced the infrastructure available to it.  This experience led to a paper co-written by Jeff and me, which is as relevant today as it was then.  The abstract follows but the full paper can be can be read in the Proceedings of the 44th Hawaii International Conference on System Sciences linked here:

Hitting the Wall: What to Do When High Performing Scrum Teams Overwhelm Operations and Infrastructure
All-at-once Scrum implementations require total commitment to change, high level management support and aggressive removal of impediments. Several company-wide implementations are known to the authors but none of them had to deal with the complexity of a large, mission-critical, enterprise software product. Pegasystems develops software to manage, automate and optimize a broad array of business processes. In July of 2009 the company deployed over 20 Scrum teams in the U.S. and India within two months. Complexity of languages, frameworks, and tools led to an architecture where continuous integration support for software development teams was impossible without a major upgrade in infrastructure and operations. A virtual Scrum team was formed to avoid "hitting the wall" before this impediment impacted the first Scrum release of the software. Here we describe how a Scrum team engineered a continuous integration environment for hundreds of software developers on two continents within a few weeks.