Describing Agile Manifesto using Causal Diagrams

Declaration of the Agile Manifesto in 2001 was a landmark event. It not only challenged the monopoly over big-process frameworks of the day such as CMM and ISO9000, but also brought together alternate methodologists who were hitherto divided by their specific and often competing methods into a common vocabulary to describe the essence behind their respective methodologies and methods. Turns out, they did have a lot in common, and they were able to distill those commonalities in a pithy text that described four core values and twelve principles behind the manifesto.

In last twenty years, Agile Manifesto has gone on from being seen as a fringe movement by a bunch of rebel freelancer process gurus to become a mainstream business paradigm that is being embraced by Fortune 500 companies and startups alike. However, in my view, a bigger value created by the manifesto was recognizing a language for describing the antecedents (i.e., what does it need as a pre-condition), moderators (what variables impact the relationships and how) and consequents (what does it eventually lead to) of the agile way of working.

I explored the idea of creating a causal loop diagram (CLD) to visualize the causal relationships between various constructs of the agile paradigm, and to describe the nature of feedback loops they create. In this article, I will start with how I see the words that describe the agile manifesto and its principles when translated, or rather visualized as causal loops. Post this, I will try to make the model parsimonious, thereby hoping to describe just the most core of the relationships without getting lost in other less significant predictors. Let’s see if that makes sense!

Note: Those unfamiliar with the concept of Causal Loop Diagram can look up literally hundreds of references available on the net. Among them, I particularly liked some of them like this, but feel free to find the ones that work for you.

Before we review the CLD, here are some of the assumptions I made:

1. The four core values don’t really describe causal relationships, per se. At best, they identify a (strong) preference for certain independent variables over others. However, they have not categorically called out either if the unfavored values have reverse causal relationship with the dependent variables, or any other intermediate effect. Accordingly, for the purposes of this article, I have considered the favored values (those identified on the left in the agile manifesto) as having a positive causality on the dependent variable, and the unfavored variables (those described to the right in the agile manifesto) as having negative causality on the the dependent variable.
2. The manifesto doesn’t explicitly call out any particular dependent variable, or the outcome we are interested in. The closest it gets is identified in the first principle — “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” I have accordingly identified Customer Satisfaction as the outcome variable, or the dependent variable for this CLD. (NB: Those who expected “agility” to be the outcome variable might feel disappointed. However, we must understand that “agility” in and by itself can’t be the end-goal. At best, it is one of the means that might get us to the end-goal of customer satisfaction, but that’s about it.)
3. As is often the case with identifying such causal-and-effect relationships, we must rely on expert knowledge to come up with specifics. Not every relationship is explicitly mentioned in a way that describes an explicit causality, but we can infer the intent from the text, and then apply expert knowledge to establish these. It is possible that some of them might not always hold, or you have a different point of view.
4. Some items of interest have been merged together to form a more cohesive variable rather than keeping them separately. To that end, some of the variable won’t be a word-for-word match with the text in manifesto, but hopefully it closest to the intent.
5. Finally, as it invariably the case, not every single details qualifies to be the item of interest. Accordingly, some of the items of lesser significance have been dropped out in favor of keeping the causal framework simple and elegant (with more on it later in the article when we get down to condense it a parsimonious model).

Well, with the assumptions out of our way, now is the time to look at the CLD. Here’s the first draft the causal loops as described in the text of agile manifesto:

I partitioned the items of interest at three key entities — the organization itself, the team (or the agile team) and the customer. Further, I tried to isolate the polarity of causal relationships into enablers (i.e. positive polarity) and impediments (i.e. negative polarity). The causal relationships have been color-coded to easily identify positive polarity (green) and negative polarity (red). We have one reinforcing loop R1 that is explicitly mentioned in the principles, but no other loops are explicitly mentioned.

First, some self-criticism. I wasn’t able to establish entire causal diagram into causal loops. The agile manifesto doesn’t explicitly call our those implicit or tacit relationships explicitly (perhaps to retain brevity), and hence in this version, I have stuck to the same principle. As a result, while the key causal relationships are apparent, not all causal loops are made visible in the diagram.

Finally, when I see the causal relationships, I recognize that if I were to call out the parsimonious model, that’s how I would draw it:

However, this is perhaps over-simplistic, and states the obvious! So, I took a step back, and this is what I got:

What this means is that technical excellence is the key predictor, or the independent variable or the predictor for the dependent variable, or the outcome variable customer satisfaction. In between, agility is the mediator, i.e. technical excellence is positively correlated with higher agility, which is in turn further positively correlated with customer satisfaction. Finally, high-performing team is a moderator, i.e. its value determines (or moderates) the degree to which the relationship between technical excellence and agility is realized.

Some people might disagree with my conclusion — in their view, high-performing team should be the independent variable, or perhaps some other form of relationship. I examined the need for simultaneously existence of both of these for the agility to happen before settling for this one. Here’s my logic: at its core, it is the technical excellence (i.e., the architecture, code quality, test frameworks, etc.) that really determines the agility. A great team can further amp it up, but if there is huge amount of technical debt, for example, even a great team might struggle to really exhibit agility. Accordingly, I draw the logical inference as shown above.

To conclude, it makes a lot of sense to describe the agile manifesto using a causal loop diagram, for it could help practitioners fully comprehend the specific cause-and-effect relationships between various items of interest, and accordingly help them apply it with better judgment rather than a blind implementation.

Lastly, I would love to get feedback. I know this diagram is incomplete and incorrect, and I look forward to improving it and making it further useful for the agile community. So, please share any feedback, and if you have done something similar, or have seen something similar, or would like to contribute to it, or collaborate, drop a line.