Thinking holistically
Definition of holistic
Relating to or concerned with wholes or with complete systems rather than with the analysis of, treatment of, or dissection into parts (© 2020 Merriam-Webster, Incorporated)
Systems thinking provides a way to untangle the complexity caused by the stochastic impacts of interrelated elements within a system. Stochastic is a mathematical term that simply means the elements that are measured—in this case, the components of our product development and organizational systems are subject to the whims of seemingly random variables. The term elements includes anything that can impact the system or be impacted by other elements within the system. In other words, elements are the parts that make up a system.
System complexity increases exponentially with the number of elements involved in the system. The mathematical expression for such growth is n(n-1)/2. Figure 4.1 is a graph that shows the exponential growth in system connections with linear growth, from 2 through to 100, in the number of participating elements:
Figure 4.1 – Exponential growth in system connections with linear growth in elements
As components are added to the system, the number of potential connections increases beyond our ability to rationalize all of the potential impacts and their causes and effects. Because of the exponential rise in the number of potential interrelationships, the complexity of the system as a whole is indeed greater than the sum of its parts.
For example, Figure 4.1 shows that there is only 1 potential relationship between 2 elements in a system, and this grows to nearly 5,000 with 100 elements. Using software developers as an example, if we have 2 people in a paired-programming team, then they will have only that 1 relationship between them while programming. If we have 10 developers within our team, then the number of potential relationships grows to 45. Increase the number of developers to 100, and the number of potential interfaces between them exponentially increases to 4,950.
In other words, the number of potential interrelationships and types of interactions in a multinode system makes it increasingly difficult to predict the total impact of any changes to the system. Instead, we have to break out and assess the elements participating in the system, by modeling their relationships and interactions between individual elements and across the system. You'll learn how this is done later in this chapter.
Visualizing causes and effects
The type of modeling used in systems thinking is called causal modeling, which evaluates the causes and effects of behaviors between elements that participate in a system. Elements include events, tangible or intangible things, processes, or states within the system. Causal modeling diagramming technics, such as the causal loop diagram (CLD), visually depicts the causal relationships between the elements identified within a system. The basics of causal diagramming include the following:
System variables are displayed as nodes.
Arrows indicate causal influence between two or more nodes.
Arrowheads indicate the direction of causality.
Causal influences can have balancing or reinforcing impacts.
Causal influence arrows can indicate the impact of a trend in the same direction or indicate an opposing impact.
Causal arrows can form paths between two or more nodes.
We'll use causal loop diagrams in subsequent sections to model systems related to IT. We'll start with a straightforward CLD of a single-element system and then add much more detail and complexity as we go along. But before we get to those examples, we need to make sure that we have a common vocabulary and understanding of the terms used in systems thinking and causal modeling.
Understanding the concepts and vocabulary of systems thinking
The concepts and vocabulary that describe systems thinking are surprisingly simple. All systems have elements and interconnections, and collectively they serve a purpose or function. All systems have stocks that change dynamically because of the flow of the stocks between elements within and across the system. The queuing of stocks within the system causes delays in flows with both positive and negative consequences. Finally, feedback loops provide information that can modify flows to bring a system into balance or to reinforce a positive or negative trend.
Before we get into the application of systems theory to Scrum and Agile practices, let's first explore the basic terms and concepts of systems theory in a bit more detail. We'll start by looking at the definitions of the more common terms:
Systems: These are complex structures of tangible and intangible things, principles, procedures, and social and political environments that collectively act together to serve some purpose or function.
Elements: This term refers to the collection of parts that make up a system. These could be tangible and intangible things, principles, procedures, or social and political environments that participate in and guide the behaviors of the system.
Interconnections: The relationships—including physical, informational, formal, or informal linkages—that bind elements together within the system.
Function: The purpose, goal, or objective of a nonhuman system.
Purpose: The purpose, goal, or objective of a human-based system.
Stocks: These are tangible, quantifiable, and measurable variables within a system that are subject to dynamic changes over time through the actions of a flow. Where the term element implies a type of thing at any given time, the term stock implies attributes of the elements that have observable values at specific points in time.
Flows: These are actions that dynamically change the directions of stocks within a system as inflows and outflows.
Inflows: These indicate a direction of flow that serves to increase the measurable amount of stock. Inflows are shown in causal loop diagrams as arrows that point to the elements accumulating stock.
Outflows: These indicate a direction of flow that serves to decrease the measurable amount of stock. They are shown in diagrams as arrows that point to the elements accumulating stock. Outflows are shown in causal loop diagrams as arrows that point away from the elements losing stock.
Delays: These are formed when inflows are greater than outflows, resulting in an accumulation of stock. Delays are typically indicated by writing the work delay on the arrow connecting elements or with a double hashmark on the connecting arrow.
Feedback loops: These are mechanisms that adjust flows to either stabilize a system or reinforce a certain trend within the system.
Balancing feedback loops: These provide information or resources that bring a system or elements within a system into equilibrium and maintain them within a desired range.
Reinforcing feedback loops: These provide information or resources that support a trend within a system or elements within a system. The trend can be either positive or negative.
Positive causal link: This means that the cause-and-effect impact of two linked nodes are changing the observed attributes in the same (positive) direction, increasing the value of the monitored attributes.
Negative causal link: This means that the cause-and-effect impact of two linked nodes are changing the observed attributes in the opposite (negative) direction.
Open systems: These are characterized by having inflows and outflows external to the system—that is, things that can enter or leave the system.
Closed systems: These are characterized by having no flows in or out of the system—that is, the system is fully self-contained.
Labels: Use labels on everything displayed within your causal diagrams so that reviewers know what the elements and links represent within your system model.
So now, let's run through a few exercises to see how the terms depicted in the preceding list help describe the workings of a system. We'll start with the most basic of systems, comprised of a single element that has both an inflow and an outflow.
Causal modeling of a single-element system
As depicted in Figure 4.2, the most basic system includes a single element acting as a stock, with some sort of incoming and outgoing flow:
Figure 4.2 – Single-element system
The system might represent a manufacturing process with the incoming flow of raw materials, a queuing of materials as stocks, and the outgoing flows of a finished product. Or the system could represent an information-oriented transaction, such as the data for a customer order moving to a queue formed in a fulfillment specialist's inbox who then reviews and approves the shipment of the product, which is the outflow.
Causal modeling of a basic Scrum Team system
The preceding system model could depict a Scrum Team working from an external set of requirements from the Product Backlog. In that scenario, the inflows are stories from the Product Backlog, the team's stocks are the work in progress, consisting of tasks and code, and their output is a product feature that meets the definition of done.
Now, let's step up the complexity a little bit by adding the two additional elements within our Scrum system model—the Product Backlog and Product Features. Note that Figure 4.3 is essentially the same display as Figure 4.2, but with additional information added to show the most basic elements of a Scrum Team as a system. The revised labels also provide more information about the types of stocks, inflows, and outflows within our Scrum system model:
Figure 4.3 – Sample Scrum Team system
From a workflow perspective, requirements flow in from the Product Backlog, forming a queue as a delay at the Sprint Backlog, from which code is developed, and the result is an outflow of new or enhanced product features. As requirements are pulled into the sprint, they temporarily sit in a queue with the development team. The delay is indicated by the double hashmarks on the Requirements arrow. If requirements come in at a faster rate than developers can create the features, then the requirements will stay in the queue, and the work in progress will build from sprint to sprint when no actions are taken to reduce the inflow or improve the outflow.
Implementing feedback loops
This model of a Scrum Team as a system is still too elementary, and in this section, we'll continue to add typical types of complexity to the system to demonstrate how system thinking is applied. So now that we have described the basic inputs and outputs of the Scrum Team system, let's put in some feedback loops.
A very common feedback loop in Scrum is the Sprint Planning event. The product owner, Scrum Master, and development team meet to assess Product Backlog priorities, determine the sprint goal, and determine the stories that support the sprint goal. The development team must also assess how much work they can complete within the sprint's duration:
Figure 4.4 – Scrum Team system with feedback loops
Figure 4.4 adds the sprint review meeting with a customer feedback link looping back to the Product Backlog. Note the - sign, which indicates the link from the sprint review's oppositional effect on the Product Backlog. In other words, the values of the two linked nodes are changing in the opposite direction. If the customers are satisfied with the features, then the effect is to remove the requirements from the Product Backlog. If the reviewers are dissatisfied with the new features, or discover the need for new capabilities, then the effect is to add those new requirements back into the Product Backlog.
Note that there is also a negative causal effect, such as the one between Done Features and Requirements. This link tells us that as the requirements are coded, meeting the definition of done, the number of requirements in the Sprint Backlog queue are reduced. If the implemented code does not meet the definition of done, then the requirements stay in the Sprint Backlog.
One final point to be made on this model is that the arrows from the Product Backlog to the WIP/Code, Sprint Review, and Released Product nodes represent the flow of requirements and features as a positive linear sequence. So, where the Done Features and Customer Feedback links are informational, the remaining arrows show the flow of tangible items in the form of requirements and features.
This is a very high-level model of a single sprint, and we can get a lot more granular in the model to further break down other parts of the sprint events. So let's do that and apply these concepts, using CLDs to show how systems thinking is applied to analyze Agile practices applied to the Sprint Planning event.