Causal Loop Diagrams
Causal Loop Diagrams (CLD) are the typical models, formalisms and tools for systems thinking. Although text books on systems thinking explains these tools very well, they are unfamiliar to most software industry professionals and practitioners. As such, we will explain CLDs with examples relevant to software industry.
Figure 4 shows an example of Causal Loop Diagram (CLD) illustrating why software process improvements remain elusive in many software-intensive enterprises. As the software project backlog grows (either because the business environment generates more demand or competition reduces or some other favorable change in business dynamics), software engineers and managers become very busy (often overloaded), experience increased schedule pressure, and do not have the time to invest in on-going software process improvements (such as training, design reviews, code inspection, test-driven development, software process measurements and metric, process improvements based on metric).
On the other hand, when the software project backlog reduces (either because the business environment generates less demand or competition increases or some other adverse change in business dynamics), there is little work; rumors of layoffs are in the air or may already be taking place; it becomes difficult to convince management to use the available time of idling engineers sitting on the bench for training them on emerging technologies and software process improvements (which is considered as immediate costs, with somewhat uncertain long-term payoff).
Figure 4: Causal Loop Diagram CLD) illustrating why software process improvements remain elusive
As shown in Figure 4, the balancing loop in the CLD (indicated by symbol B) shows that an increase in Project Backlog increases Project Schedule Variance (projects falling behind schedule), which in turn, results in an increase in Work Intensity (engineers work more intensely or for longer hours or on weekends), which in turn, increases Production Level. This is indicated by symbol “S” (indicating “Supports in the Same Direction”) next to the causal arrows from Project Backlog to Project Schedule Variance, from Project Schedule Variance to Work Intensity, and from Work Intensity to Production Level. Increased Project Schedule Variance often encourages managers to take Process Shortcuts (such as less documentation, skip some test routines) which makes more resources available for work resulting in an increase in Work Intensity.
Increase in Production Level decreases Work Backlog (less work remaining). This is indicated by symbol “O” (indicating “Supports in the Opposite Direction”) next to the causal arrow from Projection Level to Work Backlog. Reduction in Work Backlog reduces Project Schedule Variance (helps the project come back on schedule), thus creating a balancing feedback loop (hence symbol B for balancing).
As the enterprise also has software improvement processes in place, some of the work effort is expected to expended as Software Process Improvement Effort, which over time (indicated by the “//” delay symbol crossed on the arrow from Software Process Improvement Effort to Production Quality and Capabilities), improves production quality (less defects) and capabilities (higher productivity). Improved Production Quality and Capabilities becomes another means for improving Production Level.
During increased Project Backlog, often schedule pressure increases (Project Schedule Variance goes up), which necessitates increased Work Intensity. Unfortunately, this often reduces Software Process Improvement Effort, as managers perceive that they do not have the luxury of process improvements with intense schedule pressures on their shoulders. As increased Project Schedule Variance often encourages managers to take Process Shortcuts (such as less documentation, skip some test routines as explained above), it causes an undesirable side effect by also reducing Software Process Improvement Effort. These two additional feedback loops are indicated with “R” symbol as they reinforce the Project Schedule Variance in the same direction.
During bad or slow business times, there may be a reduction in Project Schedule Variance (less projects running behind schedule) leading to lower Work Intensity as there is less work to do. While this would seem to be a very good opportunity to spend resources on Software Process Improvement Effort, that often does not happen. Since there is no schedule pressure (low or no Project Schedule Variance), managers perceive no need for software process improvements as there is no visible problem or pain; moreover, they may be occupied with labor force reduction via layoffs instead of giving their attention to software process improvements.
In short, software process improvement tends to get a lot of lip service in good as well as bad business times; it may get frantic attention only when external quality inspectors or auditors are scheduled to come for an audit, or when the company executives decide to embark on winning some quality award! Such efforts may improve software processes for a short duration, but those improvements may not sustain and the enterprise is likely to see its software process maturity reverting back to a lower level.
As illustrated with this example, CLDs are an important tool to explicate mental or implicit models of different stakeholders (executives, project managers, product managers, software engineers, QA engineers, etc.) and serve as a very effective means to get to the root causes of many systemic problems. Only when the root causes are properly diagnosed with the help of CLDs and other tools, can we hope to develop systemic and enduring solutions instead of band-aids.
[Hart 2008] and [Madachy 2008] are excellent books on applying systems thinking and system dynamics to complex software engineering problems, software development processes and software dynamics.Home |New | Resources | About Us | Testimonials | Partners | Contact Us