Agile was born as a synthesis of many minds and many frameworks. That synthesis yielded a single philosophy; however since each person and framework brought a perspective to the table that philosophy has been implemented as a wide variety of methodologies and frameworks. No methodology or framework is 100% perfect for every piece of work. Perfect is binary – when the answer to is that a specific framework isn’t a perfect fit, organizations need to either find another approach or to tailor the approach to make it fit. Scaling is a form of tailoring. Process frameworks always have recognized the need to tailor the process to meet the needs of organization and teams doing the work. For example, even the venerable CMMI, often lambasted for generating heavy or static processes, actually includes practices for tailoring across the model and the process created to implement the mode. In Agile scaling often requires tailoring the processes used at the team levels to support larger efforts. While all sorts of factors can drive the need to scale or tailor Agile frameworks, typically the size of the work is the single most critical driver. Other typical attributes that combine with size and affect how scaling is approached include complexity, risk and organizational politics.
Size of an effort is influenced by the amount functional, non-functional or technical requirements required to solve a specific problem. How related or integrated those requirements are will affect how work is organized, and therefore the number of teams required to deliver the work. A large, highly-related effort will required coordination, which will require added processes such as a Scrum-of-Scrum meetings or other forms of program management.
Complexity is is made up of a huge number of attributes that include (but is not limited to) how difficult the technical problem will be to solve, whether the team has ever used the technology before, how many disciplines will be involved in solving the problem and size. Complexity directly relates to how difficult the work will be to deliver. All things being equal, the more complex the more effort will be required. The larger the effort or the more disciplines needed to deliver the project typical means more teams and more coordination. More effort, more disciplines or more people leads to a need for techniques to scale team-level Agile.
Risk is reflection of uncertainty. Any event that could have a negative (or positive) impact that the team or organization can’t predict is risk. A risk that can have a significant impact on work or the organization as a whole needs to be monitored and managed. Risk management techniques are commonly added to scale Agile frameworks.
Organizational politics might be considered specialized type of complexity. Typically organization politics generates higher need for oversight and reporting in advance of typical team-level Agile techniques. The added organizational requirements that are required generate the need to add steps, processes and reviews, which will require scaling basic team-level Agile.
Not all projects are exactly the same. This is why we need to scale team-level. Team-level Agile smoothes some of the required process differences out through the use of techniques such as time boxes and user story grooming. However despite of these techniques, variability of work effort (examples of work efforts include projects, programs, release or products) are not all the same. Size, complexity, risk and organizational politics generate a need to add steps and processes on top of team-level Agile to scale up to meet the needs of larger, more complexity or riskier work.