Supporting Agile working through systems thinking

In this section, you will learn how to apply systems thinking to work through the entities and relationships involved in analyzing the Sprint Planning event within Scrum. Sounds like a relatively small and simple task, right? Let's find out.

Diagramming causal linkages in Sprint Planning

We do not need to continue adding to our original Scrum Team system models when we are trying to focus in on one particular area within the system. Moreover, the causal diagramming loop modeling approach is better suited to modeling larger and more complex systems. In this section, we will introduce the causal loop diagram, modeling the elements and linkages within Sprint Planning. Look at Figure 4.5:

Figure 4.5 – Elements identified governing the Sprint Planning event

In this model, I have identified the elements related to Sprint Planning, as depicted in the previous figure.

Modeling the requirements flow

Now we need to explore the individual links between these elements. We'll start with a model of the relationships between customer and end user requirements and the flow of items from sprint reviews and external sources.

In Figure 4.5, customer and end user requirements flow to the Sprint Planning process from the previous sprint review and from other external sources that the product owner has collected. This is our first example of a causal loop diagram, with many more to follow in this chapter.

The arrows show that there is a positive causal relationship between the requirements and their flow into the sprint review and product owner. There is also a positive causal relationship between the flows and the Product Backlog. In other words, and in all cases, the values of all the linked nodes are changing in the same direction:

Figure 4.6 – CLD model of analyzing Product Backlog priorities

Now that we have modeled the elements and relationships involved in creating the Product Backlog, let's look at the elements and relationships involved in refining the Product Backlog.

Modeling Product Backlog refinement

If we had a large whiteboard or an electronic equivalent, we could continue to build our Sprint Planning event model from the Product Backlog model shown in Figure 4.6. To keep each part of the Sprint Planning model manageable for a book format, I'm going to break each aspect of Sprint Planning into a separate CLD model:

Figure 4.7 – Open CLD model of Product Backlog refinement activities

Figure 4.7 shows the flow of information during the Product Backlog refinement process. This section does not form a loop, and that's OK, since we are only looking at a subset of the larger Sprint Planning event model. This component of the system is closed by other segments that we'll look at later in this section.

This segment starts with the number of items in the Product Backlog node and flows to the refined items and prioritized items nodes, before ending with the sprint goal definition node. Note that the first three nodes have a negative causal link. The Product Backlog holds the entire subset of identified requirements, but only a smaller set of the items makes it through the refinement and prioritization activities. On the other hand, the flow of Product Backlog items from the refinement and prioritization activities has a positive causal link, as the selected items add information to the sprint goal definition activity.

Modeling design and task clarifications

The next set of activities related to Sprint Planning have to do with determining the design and scope of work necessary to finalize the sprint goal. This segment includes the previously identified Defined Sprint Goal in context with Product Backlog priorities node.

Figure 4.8 includes two loops. The bottom loop shows how the sprint goal impacts both the product design and work-scoping efforts, and how both have a positive causal relationship. The upper loop includes a couple of important causal relationships. First, the product design activities impact the scope of work required to complete the development effort. In addition, both the design and scoping efforts are impacted by clarifications from the product owner, customers, users, and other stakeholders:

Figure 4.8 – CLD model of design and work clarifications

Typically, the development team directly seeks out those experts for clarification of requirements, and those interactions could be included in our CLD model; however, I would also argue that the impact of those interactions is outside the Sprint Planning system, unless the impact of the interactions serves to delay the clarification process. If that situation occurs, then I would add them to our CLD model.

At this point, we have a couple of paths to follow: we can follow the path that describes the negotiation and tradeoff activities with the product owner or we can look at the path the development team takes to determine the work that is required and their capacity to complete it in the upcoming sprint. Let's start with a model of the onward path.

Modeling sprint capacity assessments

The CLD shown in Figure 4.9 provides a visual model of the entities and relationships identified that were identified to compare the anticipated work to the team's capacity. The assessment begins with the Define Design requirements node, which has a direct and positive impact on the work-scoping effort. In other words, the Scope of the work effort node changes in the same direction as changes to the design:

Figure 4.9 – CLD model of analyzing work against team capacity

The model retains the Obtain item clarifications from P.O. and other sources node, as the input is necessary to fully assess the design requirements and the scope of work required to develop the desired features and functionality. The scoping effort has a direct and positive causal relationship with the Type of work in Sprint Backlog node. In other words, as the scope of work is identified, the type of work required to support the development effort moves in the same direction.

The type of work that is identified has a direct and positive impact on the Define initial tasks node, as the identified tasks are dependent upon the identification of the scope of work and type of work proposed for the Sprint Backlog. Similarly, as the initial tasks are identified, the team can begin to self-organize, allocating work to those who are best suited to complete each task, as depicted in the direct and positive link to the Self-organize teams around identified work node. At the same time, the development team must decide how much work they can take on, which is identified in a direct and positive link to the Determine team capacity node.

The Determine team capacity node has direct and positive impact on the team's ability to self-organize, and on the number of items selected for the Sprint Backlog. Both of those relationships are direct and positive, indicating the impacts' trend in the same direction. For example, when the team's capacity allows the inclusion of additional work, the number of items in the Sprint Backlog increases and the team is better able to self-organize in support of the work. Likewise, the items in the Sprint Backlog and the team's ability to self-organize are limited when the team's capacity is limited.

As complex as this visual model already is, this section of the Sprint Planning process can be enhanced. For example, the development team may consider adding elements and linkages to indicate the skills within the development team, as that relationship has an impact on the team's capacity and ability to effectively self-organize to accomplish the proposed work.

We're almost done with the construction of our CLD diagram for Sprint Planning. What remains is modeling the elements and relationships that define the sprint negotiations and tradeoff activities.

Modeling sprint negotiations and tradeoffs

Figure 4.10 displays a CLD diagram that models the negotiation and tradeoff activities that the development teams conduct with the product owner to bring the scope of work in alignment with their capacity to deliver within the sprint. This visual diagram starts with the Define Design requirements node and loops to the left to indicate a direct and positive relationship with the Determine tradeoffs node.

In other words, as the design complexity changes, which also involves feedback from the work-scoping and clarifications loop, the tradeoff options change in the same direction. If the design and work is more than the team can take on, or there is insufficient information to start the development work, then the development team must meet with the product owner to evaluate potential tradeoffs and to possibly renegotiate the scope of work anticipated for the sprint:

Figure 4.10 – CLD model of negotiations and tradeoff activities

The link between the Determine tradeoffs node and the Negotiate items included in Sprint node is direct and positive as changes in the tradeoffs require similar changes in the negotiations. In other words, a request for a tradeoff requires a similar agreement in the negotiations, and vice-versa. One the negotiations are complete, the number of items included in the Sprint Backlog change in the same direction, as indicated by the direct and positive causal arrow between the Negotiate items included in Sprint node and the number of items in Sprint Backlog node.

We have now modeled all the primary elements and relationships involved in the Sprint Planning event. So far, the individual CLD diagrams have modeled individual loops to make it simper to discuss and display important activities, participants, and relationships within the Sprint Planning event. In actual practice, the participants in the modeling effort would collaborate on the entire Sprint Planning event and build the CLD model incrementally as they identify participating entities and relationships. We'll see what this looks like in the next section.

Putting it all together

When a team is working collaboratively at a large white board, they may choose to brainstorm the Sprint Planning event to define the entities and relationships incrementally, and in an ad hoc manner. In other words, they may come up with a lesser or greater number of entities and relationships, and these may not be defined in the order presented in the previous sections. They may also have a different set of entities and relationships, depending on how they conduct Sprint Planning. Over time, they will expose the entire model, and it can be quite large and complex, as shown in Figure 4.11. This CLD diagram shows all the elements and relationships for Sprint Planning previously described in this chapter:

Figure 4.11 – CLD model of the Sprint Planning event

The Sprit Planning event is but one component of the Scrum framework. Other Scrum events and roles have equal levels of complexity that should be modeled by the participants most affected. Every product-development effort is unique, and the Scrum Teams should model their identified entities and relationships to understand the complexity of their product-development systems.

In addition, modern systems often involve the simultaneous development of multiple and integrated components and products. Coordinating events across development teams that are working across portfolios and programs adds to the complexity. Systems thinking is necessary to deal with such complexities. We'll explore how systems thinking is an important analysis tool for developing large and complex products in the next section.