Applying systems thinking to large, complex, and integrated products
I've noted in previous sections that the original developers of Scrum, Jeff Sutherland and Ken Schwaber, both intended it to scale beyond the small product or single project. Interestingly, both Sutherland and Schwaber have extended the basic Scrum concepts to include new guidance on methods to scale Scrum across large products and at an enterprise level.
For example, Jeff Sutherland founded his new company Scrum@Scale for this purpose, and Ken Schwaber introduced his Nexus framework at Scrum.org for scaling Scrum.
We'll discuss both of these Scrum scaling approaches, along with several others, in Section Two of this book. But before we get to those chapters, we need to understand how systems thinking aids in the analysis required to deal with the increasing complexity of scaling Scrum, Lean, and Agile practices on an enterprise scale.
Putting the focus on products, not projects
In this section, you'll learn how to use systems thinking to analyze the complexities of deploying and maintaining multiple teams working on developing a single, large, and complex product. Before we begin, let's start by taking a quick look at how large projects were managed under the traditional project-based development model. This comparison helps set the as-is baseline that most organizations start from before we move on to Scrum.
Traditionally, using program-management concepts, the oversight of large and complex product-development efforts fell to the program manager and their program-management office (PMO). Under the traditional systems-development life cycle (SDLC) model, the program manager and PMO staff break up the overall work effort across multiple project teams, and the integration of work is managed via an integrated master schedule (IMS).
There is no fast rule on how to divide development work activities. The work assigned to each project team may be broken down by systems, applications, modules, types of related functionality, skills, or other criteria. Each project team defines the activities and tasks necessary to produce and deliver their assigned deliverables and then sends their planned schedules and updates back to the PMO for inclusion within the IMS. In other words, the IMS includes all identified deliverables and related activities and tasks supporting the authorized scope of work and spanning all participating project teams.
By definition, all programs and projects have constraints on budgets, time, scope of work, deliverables, resources, and quality. These constraints form the boundaries for what's in and what's out of a project.
Moreover, project-management philosophies hinge on the principles that all project-based work is unique and, therefore, at least some of the details are identified or fine-tuned throughout the project. The project's constraints help the executives monitor progress against the budgets and schedules that justified the investments, and help prevent unapproved scope creep from setting in.
The traditional project-management model does not look at the long-term life cycle requirements of developing, maintaining, and enhancing a product. New programs and projects must be approved, typically on an annual budget cycle, to address new product requirements or enhancements that were not identified in the previous program or project specifications. Consequently, project-based development philosophies are not inherently responsive enough to address evolving market opportunities or changes in customer or end user needs.
Scrum eliminates project-oriented practices and instead puts the focus on products. Moreover, continued development and support activities are sustained across the life of the product. Ideally, each new budget cycle simply determines the amount of funding required to sustain the development and support team activities for each product over the next fiscal planning period, until the product reaches its end of life.
Let's move on and look at some of the elements and relationships involved in transforming the development activities from a program or project-oriented development activity to a product-oriented development activity. As with the Sprint Planning CLD modeling activity, we'll start by identifying the elements and relationships involved in this transformation.