Who needs “Agile”? Transforming an organization along these three dimensions achieves the same intent, all without the baggage provoked by a loaded term.

agile-minus-Agile

or: Why Agile Makes me Cringe and

What I Did About It

Sean Dunn, CD, PEng

I cringe at the word “Agile”. As someone employed as a full-time “Agile Coach”, I can appreciate the hypocrisy, although I am not the first to become so disillusioned— notably, Dave Thomas and James Shore have expressed similar sentiments. What is motivating this (increasingly common) aversion to Agile? More importantly, how does this impact our ability to develop organizations, and is there something we should do about it?

“Agile”, as used most often in conversation, tends to refer not to the values and principles of the Manifesto, but rather to the ever-expanding Manifesto-inspired body-of-knowledge: Scrum, Kanban, Continuous Integration, TDD, servant-leadership, BDD, etc… On a daily basis, we are learning more about the intertwined relationships between product development, technology, sociology, leadership, psychology, economics, complexity theory, and how we can apply these new insights to work better. Of course, as this body-of-knowledge expands (as it should), the term “Agile” dilutes, the natural consequence of Agile achieving its mandate: “uncovering better ways of developing software by doing it and helping others to do it.” Agile’s manifest destiny was always to out-grow itself; it could never perpetually encompass the entirety of knowledge it inspired us to uncover.

Of course, it becomes increasingly difficult to develop and coach organizations based upon an ever-growing body-of-knowledge. When coaching at an enterprise-level, “Agile” is almost always a loaded word, with many preconceptions that hinder, rather than help adoption. Standing in front of executives while pointing at the Manifesto and proclaiming “this is Agile!” is rarely productive, nor is pointing at a Scrum diagram and suggesting that a process will solve all their problems.

For these reasons, I avoid the word “Agile” entirely. I cringe when someone else uses it, as their mental model of “Agile” is usually much different than mine. “Agile”, being too abstract to identify these differences, leaves us to muddle on with disparate mental models and no meaningful vocabulary to reconcile them. Ultimately, the word “Agile” just isn’t useful — it’s not useful in conversation, and it is not useful in coaching and developing organizations.

So, if not “Agile”, then what? When assessing, coaching and developing organizations at the enterprise-level, I needed my own mental model of what “Agile” meant, while avoiding a loaded term and without reciting a specific methodology. To me, Agile could be described by three distinct dimensions: Lean Product Management, Transformational Leadership, and Technical Excellence. With these axes, I found myself better equipped with a framework for engaging all-levels of the organization using terms that resonated with them:

Lean Product Management. Pioneered and made popular by the likes of Mary and Tom Poppendieck, Don Reinersten, and Eric Reis, Lean Product Management refers to the application of the scientific method to product development: generating hypotheses, testing these hypotheses in the market with minimal investment, and using validated learning to inform development prioritization.

Pioneered and made popular by the likes of Mary and Tom Poppendieck, Don Reinersten, and Eric Reis, Lean Product Management refers to the application of the scientific method to product development: generating hypotheses, testing these hypotheses in the market with minimal investment, and using validated learning to inform development prioritization. Transformational Leadership. Based on the work of Presidential Biographer James Burns, Transformational Leadership encompasses the implied leadership model of the Manifesto: “emphasizing intrinsic motivation and positive development of followers”; “highlighting important priorities”; “providing individual coaching and mentoring for followers”; “encouraging followers to look beyond self-interests to the common good”; “allowing freedom of choice for followers”; “promoting cooperation and harmony”; and “using persuasive appeals based on reason”.

Based on the work of Presidential Biographer James Burns, Transformational Leadership encompasses the implied leadership model of the Manifesto: “emphasizing intrinsic motivation and positive development of followers”; “highlighting important priorities”; “providing individual coaching and mentoring for followers”; “encouraging followers to look beyond self-interests to the common good”; “allowing freedom of choice for followers”; “promoting cooperation and harmony”; and “using persuasive appeals based on reason”. Technical Excellence. This represents all the practices (and the pursuit to improve these practices), which makes us masters of our craft. In the software domain, this would refer to designing software to accommodate change, continuous integration, clean code, etc…

Here are the advantages I have found of this model:

It encompasses a whole-of-organization approach . These three dimensions effectively communicate the breadth and impact across the entire organization; it conveniently avoids leaving the impression that “this is just something the software developers do.”

. These three dimensions effectively communicate the breadth and impact across the entire organization; it conveniently avoids leaving the impression that “this is just something the software developers do.” It uses terminology that resonates at all-levels. Step 1: Know your audience. Lean? Leadership? Excellence? Watch every MBA in your organization giddily jump aboard.

Step 1: Know your audience. Lean? Leadership? Excellence? Watch every MBA in your organization giddily jump aboard. It is industry agnostic . Nothing of this model is suggestive of a particular domain (such as software). I can see no reason why this model would not be equally valid in any industry.

. Nothing of this model is suggestive of a particular domain (such as software). I can see no reason why this model would not be equally valid in any industry. The dimensions are meaningful independently. A company could undertake an initiative to “improve leadership development”, or to “improve technical competencies” or “become Lean”, without any attention to each of the others. This helps to scope and focus conversations, especially in early stages of a transformation.

A company could undertake an initiative to “improve leadership development”, or to “improve technical competencies” or “become Lean”, without any attention to each of the others. This helps to scope and focus conversations, especially in early stages of a transformation. The dimensions are mutually supportive. The whole is greater than the sum of the parts. Although each dimension could be viewed independently, growth along one axis enhances the others non-linearly. This interaction between the dimensions leads to even more interesting conversations: technical excellence enables lean product management; transformational leadership enables technical excellence; decentralized decision making is critical to Lean thinking.

The whole is greater than the sum of the parts. Although each dimension could be viewed independently, growth along one axis enhances the others non-linearly. This interaction between the dimensions leads to even more interesting conversations: technical excellence enables lean product management; transformational leadership enables technical excellence; decentralized decision making is critical to Lean thinking. It is ambivalent to process. No part of this model makes any suggestion of process; rather it emphasizes behaviors and decisions.

No part of this model makes any suggestion of process; rather it emphasizes behaviors and decisions. It is non-linear . Three dimensions suggest an infinite number of paths to reach any given point. Thus, it accurately reflects the complex growth path of an organization, depending on their starting maturity in each of the three dimensions.

. Three dimensions suggest an infinite number of paths to reach any given point. Thus, it accurately reflects the complex growth path of an organization, depending on their starting maturity in each of the three dimensions. It explicitly calls out the importance of leadership. Much of the Agile Manifesto dances around the importance of leadership, without actually calling it out. If Agile is a culture more than a process, we have to explicitly acknowledge the role of leadership in shaping and influencing that culture, and deliberately developing leadership consistent with our values.

Much of the Agile Manifesto dances around the importance of leadership, without actually calling it out. If Agile is a culture more than a process, we have to explicitly acknowledge the role of leadership in shaping and influencing that culture, and deliberately developing leadership consistent with our values. It is grounded to theory. Economists, psychologists and sociologists have extensively studied Lean and leadership for decades, generating a wealth of research and knowledge in these subject areas. This model traces practices to economic and sociological principles, thus providing a degree of legitimacy and avoiding dogmatism.

Economists, psychologists and sociologists have extensively studied Lean and leadership for decades, generating a wealth of research and knowledge in these subject areas. This model traces practices to economic and sociological principles, thus providing a degree of legitimacy and avoiding dogmatism. It avoids the loaded term “Agile”. Using this model, an organization could eliminate completely “Agile”, “Scrum” and “Kanban” from their corporate vocabulary (or never introduced in the first place); if such an organization simultaneously pursued growth along the model’s three axes, they would entirely achieve the intent of the Manifesto. All without “Agile”.

Is this model perfect? Of course not. “All models are wrong, but some are useful.” For the purposes in which I use this model, namely enterprise coaching, I find it useful. One may claim that Lean already encompasses all three dimensions, however, reducing the model simply to “Lean” defeats the original intent of more granularity than a single word to represent a large body-of-knowledge.

Is this the only model of Agile? Of course not, nor should we attempt to be seeking a “unified model.” Different models are useful for different applications, and there are others out there that are also very useful (The Agile Fluency™ Model is one of note [Larsen and Shore]). I believe my model is useful for the purposes in which I apply it, and has certain advantages. Other models have advantages for different purposes. We should know by now that context matters, so use judgement to apply appropriately.

I share this in the event others may find it useful, or may suggest improvements or have other mental models they wish to share that will prove to be much better.