Applying systems thinking to enterprise implementations of Scrum

The organizational structures, roles, and responsibilities in Scrum are very different than those employed in the traditional hierarchical organization that employs program and project-management concepts to deliver products. Scrum eliminates the need for functional departments and flattens the organization by providing only three roles: product owner, Scrum Master, and developers. Scrum also eliminates the need for detailed project planning and scheduling, and instead employs empirical process control concepts to iteratively deliver new increments of functionality as market, customer, and end user priorities dictate:

Figure 4.17 – Identified elements involved in an enterprise Scrum implementation

In the previous section, you learned how to begin to assess the elements that could potentially impact a project-to-product development team transformation. In this section, you will learn how to apply systems thinking to an enterprise-scale deployment of Scrum. This section is not meant to provide an all-inclusive systems-oriented assessment of the project-to-product team transformation. But it will serve as a starting point for you and your teams to think about your unique transformation situations.

As with the previous two sections, the Scrum implementation analysts use the same CLD diagramming techniques to assess the causal relationships between elements in the enterprise Scrum transformation program. Figure 4.17 provides the list of elements identified for the enterprise-scale Scrum transformation activity.

Modeling the business drivers affecting business transformation decisions

Similar to the large product Scrum implementation, this model starts with a set of issues that can drive executive management to look to some type of major organizational transformation initiative. The business drivers identified include a burning platform, seeking a competitive advantage, the pursuit of market opportunities, more responsiveness, and the reforming of bloated, bureaucratic, and unwieldy organizational structures:

Figure 4.18 – CLD model of business drivers affecting business transformation decisions

All of these elements provide direct and positive impacts on the organization's executive in providing some sort of business transformation, such as the implementation of Scrum on an enterprise scale. Once that decision is made, resources are required to eliminate any impediments to the transformation.

Modeling the impact of resources to remove organizational impediments

Figure 4.19 shows the resources identified to carry out the enterprise transformation to Scrum. The resources identified follow Scrum's basic guidelines on limiting roles to those of a product owner, scrum master, and Scrum team members. The primary difference in this model is that these roles operate at an enterprise level, and the product they support is enterprise Scrum:

Figure 4.19 – CLD model of resources to remove enterprise-level impediments

Additional resources for Scrum training, coaching, and mentoring are also identified as necessary elements to eliminate impediments to the enterprise deployment of Scrum. All relationships identified in this CLD model of the resources required to remove enterprise-level impediments are positive. As resource requirements increase, the resources should respond in the same direction. Likewise, as enterprise Scrum resources become available, the organization's ability to remove impediments increases.

Modeling the impact of Scrum Team needs assessments

Figure 4.20 is a larger and more complex CLD model that depicts how a decision to implement Scrum on an enterprise-scale affects the development of Scrum Teams, not only at the product-development level, but also across product-support functions. The identified product-support teams in this model include development, marketing, partnerships, product support, delivery support, and supply chain.

There is no single or correct way to align organizational resources in support of its products. Not every organization requires all of the product-support functions listed, while other products may have additional support requirements. This model stays purposely at a very high level. Ideally, the enterprise Scrum product owner will identify functional teams to model each of the product-support functions and ultimately determine the best structures for their enterprise Scrum implementations.

To simplify this model, I have bounded the Type Scrum Teams and Scrum Teams within rectangular boxes. Each of the types of Scrum Teams require a deeper dive to understand the elements and relationships that impact the organization's ability to provide adequate support services for each of their products. Each type of team requires further assessment on the number of teams required, the number of people needed to support each effort, and the necessary skills and experiences of those team members.

Figure 4.20 is not a closed loop. The loop is closed when other elements are included in later sections. Instead, this section of the larger CLD diagram shows how the need to align organizational resources around products impacts decisions on product definitions, Scrum Team needs assessments, the functional activities of identified Scrum Teams, and training, coaching, and mentoring requirements. All relationships are positive, meaning that the impacts trend in the same direction between elements:

Figure 4.20 – CLD model of Scrum Team needs assessments

For example, the impact of deciding to align organizational resources around products leads to an increase in the need to define products. With an increase of defined products, there is an increase in the need to assess Scrum Team requirements. An increase in the Scrum Team needs assessments leads to an increase in defining the functions of identified Scrum Teams. The identification of Scrum Team functions leads to further definition of the types of Scrum Teams required, which also has a positive impact on the definition of Scrum Team Member requirements.

Modeling the elements supporting Scrum events and Scrum Team deployments

At this point in the model, we have analyzed the business drivers that impact the executive decisions to seek business transformations and identify the need to install a team to work through the impediments of the change initiative. Next, we explored the types of resources needed to manage the enterprise-scale transition to Scrum and its impact on the organization's ability to addresses impediments that hinder the transition. Finally, in the last section, we looked at the elements involved in defining the organization's products, determining the supporting functional requirements and types of Scrum Teams and resources needed to support those efforts.

Now, in Figure 4.21, we will look at the parts of the enterprise Scrum implementation system that both impact and support the organization's ability to roll out the Scrum Teams on an enterprise scale. The assessment starts with the same Scrum Team requirements box identified in the previous Figure 4.20:

Figure 4.21 – CLD model of the rollout of Scrum Teams and events

In the CLD model, the identification of the need for Scrum Team Members has a positive impact on the need to provide training, coaching, and mentoring to ensure each team's success. In turn, the training, coaching and mentoring allows the identified Scrum Teams to support the Scrum events as they deploy.

The ability of the teams to support Scrum events, as each are stood up, has a positive impact on the organization's ability to plan the rollout of the Scrum Teams, initially as pilot engagements. The success of the pilot engagements, or lack thereof, has a direct and positive impact on the organization's ability to proceed with a staged rollout of additional Scrum Teams. Now we can look at how the staged rollout impacts the business drivers that caused the enterprise Scrum transformation.

Modeling the elements that close the loop to address business drivers

We left off with the staged rollout of Scrum Teams in the last section. Figure 4.22 shows that the staged rollout of each new team has different impacts on each of the business drivers that justified the organizational transformation to enterprise-wide Scrum:

Figure 4.22 – CLD model of Scrum Teams' impact on business drivers

Again, remember that the positive sign indicates that the changes between the elements trend in the same direction, while a negative sign indicates that the trend between elements is oppositional. So this section of the model indicates that each successful deployment of a Scrum Team reduces the impact of the burning platform situation, reduces the size and complexity of the organization, and decreases the organization's reliance on or need for hierarchical and departmental structures.

On the other hand, each successful Scrum Team deployment improves the organization's competitive advantage, allows the organization to pursue attractive market opportunities, and be more Agile (that is, more adaptive) and responsive to their customers' and end user needs.

Modeling the entire enterprise Scrum transformation

Now, as shown in Figure 4.23, we can put the entire enterprise Scrum transformation model together. This is a highly simplified model; in a real-world situation, this model would only serve as an initial baseline for the transformation. Many of the elements would require much deeper analysis, with increasingly complex CLD diagrams, to explore all the potential elements involved, and their cause-and-effect relationships:

Figure 4.23 – CLD model of enterprise Scrum transformation

If you have a keen eye, you may have noticed the hashed lines added to the preceding CLD model. These represent delays in the effects of the relationships between nodes. We'll take some time in the next section to better understand the potential cause of the delays.

Modeling delays between enterprise Scrum transformation elements

To keep things simple, I haven't yet addressed the subject of delays since the initial model of the sprint cycle in Figure 4.1. Now that the baseline model is complete, let's take a look at some of the more obvious relationships that may experience delays between causes and effects.

As noted in the previous section, the CLD displayed in Figure 4.23 includes double hashmarks (//) on several of the arrows. These hashmarks indicate delays between causes and effects among the connected elements. Depending on each organization's unique circumstances, there may be causes for delays at virtually all of the elemental connections. But to keep things relatively simple, let's focus on these.

Note that all of the business drivers connected to the chief/L.O.B. executives which delay the business decisions for transformation elements. The delay occurs because it takes time for the chief executives to diagnose the issues, and to set a course of action.

Another potential source of delays is in the provisioning of training, coaching, and mentoring services to newly formed Scrum Teams. Likewise, their ability to effectively implement Scrum events is dependent upon the time it takes for the individuals and team as a collective to master the elements of Scrum.

Finally, there is a delay between the deployment of the pilot Scrum Teams and the communications of their efforts. Until product features are released and available for demonstration, there is not much to report, and there will not be a commercial success to indicate a success until the product is released.