One myth about agile approaches goes something like this: "APM (or pick any agile methodology) works well for smaller projects, but it doesn't scale to larger ones." To combat the myth, I'd offer a couple of questions: "At what project team size do the core values of creating innovative products and adaptive teams based on self-organization and self-discipline fail to be important?" or "In today's economy, what size company can afford to become static and rigid?" Large project teams and large companies must be agile in order to keep up with competitors . Larger projects scale up by continuing to apply agile principles, creating a larger self-organizing framework, and applying additional practices.
Agility is a mindset, a way of thinking, not a set of practices or processes. The lifecycle framework and practices outlined in this book encourage agile behavior; they reinforce the principles, but they don't define APM. The core values and guiding principles of APM are key to scaling.
In a project management discussion forum, Glen Alleman, VP, Program Management Office at CH2M Hill, described the practices he used on a moderately sized project for the US Department of Energy. Because it was a government contract, a number of specific practices were required. As he described the team's practices, the list appeared to define a heavyweight, not an agile, project management framework. However, the team applied agile principles to the practices they used, trying to keep them as simple as possible given the nature of the agency and contracting requirements. They utilized short iterations and feature-based planning. They used a customized version of earned value analysis. They adjusted based on feedback each iteration. This was an agile project team, even though it was using what might appear on the surface to be nonagile practices. Alleman's team illustrates the point that APM is more about attitude than practices, or more precisely, that agile teams use their guiding principles to shape the processes and practices to the job at hand.
Many of the misconceptions about scaling to larger projects come from managers who focus first on organizational structure (matrix, hierarchy), process (phases, tasks , artifacts), and development practices. They tend to build scaling mechanisms based on hierarchy, control, documents, and ceremonywhich slowly but surely cause compliance activities to dominate delivery activities as each hierarchical level justifies its existence. On this drift toward compliance-based management, Dee Hock (1999) comments, "Management expertise has become the creation and control of constants, uniformity , and efficiency, while the need has become the understanding and coordination of variability, complexity, and effectiveness."
Agile teams balance flexibility and structure. So as project size increases , structureof necessityincreases also. But we don't have to revert to an authoritarian, hierarchical structure. Large organizations can be adaptive, flexible, and exploratorythey just have to expand their structures in concert with agile principles, not abandon them.
There is a plethora of organizational structures, processes, and practices that can be used on larger projects, but they are beyond the scope of this book. What I want to convey in this chapter is how to think about scaling these structures, processes, and practices in an agile way, in a way that increases structure but retains the essence of flexibility and semi-autonomy at the individual and subteam level.
But before launching into a discussion about scaling, there is another issue that arises when companies begin using agile development: Team sizes frequently decrease, obviating the need for more structure. The right small to medium-sized team (25 or fewer people) utilizing an agile framework and practices can often accomplish more than a significantly larger team. So before figuring out how to scale up to a larger project team, consider the possibility of deploying a scaled-down team using agile project management and development to accomplish your goals.