BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles The Death of Agile and Beyond

The Death of Agile and Beyond

Leia em Português

Bookmarks

Key Takeaways

  • There is a growing unease that many Agilists feel with state of agile
  • There appears to be legitimate reason to ask has agile failed, is Agile dead?
  • What is the impact of Agile being adopted in domains outside software development and at enterprise scale?
  • Agility is a state of being and there is much we can learn about organisational change from other disciplines
  • While there are definitely challenges, the future of agile as philosophy of work is positive

I was discussing the current state of agility with few fellow Agilists, and we ended up questioning if agile has failed us? Our discussion was triggered by Maurice Hagar’s recent article Maybe Agile Is the Problem. The article resonated with us; it resurfaced a growing unease that many Agilists feel. And we all agreed on one point: there is something not quite right: I personally face this every day, in many conversations (online or in-person); there is a growing feeling of unease among many Agilists that cannot be ignored. The angst is manifested in many ways; and we articulate it in our own ways. I believe 3 questions remain constant in many of these discussions: 1) Is agile failing? 2) what can we (Agilists) do about it? and 3) (occasionally in despair we ask) if agile is the problem?

New Agile Landscape

Before I go on further, let me take a stock of the landscape of agility as I see it. We are in an era of agile expansion; we have evolved from "…uncovering better ways of developing software…" to embracing better ways of delivering value by enabling teams to solve emerging and evolving problems. I personally believe this to be a great thing; there are many domains outside software development that benefit from internalizing and adopting the agile values; we have seen people building cars, teaching school students, and developing a cure for blindness to name just a few. The success of agile adoption across domains has a few distinct impacts:

  1. It has triggered enterprise-level adoption
  2. It has created a (perceived, at a minimum) need for scaling
  3. We have now taken on the world of enterprise transformation.
  4. It challenges the manifesto as it stands

These impacts, on their own (yes, even number 4; more on that later) are positive, we are spreading the agile goodness vertically and horizontally, we are engaging new domains and involving different types of practitioners. However, as Michael Lewis said: "There is something bad in everything good…". The enterprise-level transformation and adoption of agile, for example, has some positive and some negative implications; one of the negative by-products is massive-scale Faux Agile. And it has such profound impact that it almost feels like we have lost the plot; agile has failed us and we have failed agile. I understand that it might sound like I am trying to pass the buck here, but let me quote Martin Fowler (one of the original signatories of the Agile Manifesto) here: "our challenge now is dealing with faux (fake) Agile." Let us pause and (re)define Faux Agile here.

Let’s talk Faux-Agile

Faux-Agile has been around for years, but with the enterprise-level transformation and more and more organizations feeling the urge to do agile what we are facing is a complete shift in paradigm. We are not talking about incoherent cases of putting the agile lipstick on pigs, we are talking about a mass-adoption of frameworks and methodologies in the name of agility that has little to do with agile philosophies or the mindset; so much so that we need to question if agile is dead and feel the urge to devise something better.

Much has been said about Faux Agile or Dark Agile over the years and much of this dialogue focuses on practices, processes and mandated implementations. I personally find over-emphasis on the processes/practices when calling out Faux-Agile problematic.

For me, it boils down to 2 things; the spirit, and not the letters of the Agile Principles and mindset. Anything and everything that is done in the name of Agile and Agility disconnected from the spirit of the agile values and principles is Faux-Agile, be that adoption of practices, processes or implementation of frameworks.

This matters now more than ever because of the magnitude of the problem. We have managed to get caught in a vicious cycle; we are making agile popular and creating demand, which in turns enables massive-scale faux-agile, which in turns create more (often naïve) demand and mandated implementation and dogmatic adoption of practices and processes and so on.

Let’s start with the "demand" first, before we dig further into this cycle.

Semantic Satiation

As Maurice pointed out in his article semantic satiation, is one of the key factors in the vicious cycle of enterprise-scale-faux-agile phenomena.

We have "agilised" everything; as we have stepped into newer domains outside the software development, we invented new agile terms over and over again. There is agile data analytics, agile infrastructure, agile marketing and my most recent discovery, agile Gantt charts.

With agilization, which is basically pre-fixing everything with Agile-, we have devalued the word "Agile". We have forgotten what it means, so that it does not mean anything anymore. This lack of meaning is problematic, it creates a vacuum and a space for anyone (probably sometimes with the best intention) and everyone to use words in ways that are dissociated entirety from the agile values and principles. It also shifts the focus constantly away from principles, values and mindset and into practices and processes.

Another impact of semantic satiation is that Agile becomes the norm; the "right" thing to do, the "in" fashion, which takes us to my next point.

Agile is eating the world… and nobody knows the "Why"

Despite the cry that from the agilists that agile is dead/failing, it remains popular and is becoming increasingly "fashionable" among the senior executives. Surveys by Deloitte and McKinsey show that more than 90% of the executives believe that "becoming agile" is a high priority. And of course, any high priority aspiration often comes with a mandated time-constraint.

The first problem with these aspirations is the imposition; they rob people of the opportunity to choose agile as a way of being. However, the bigger problem is that these aspirations are missing a key element: the sense of why.

Think of impact mapping for enterprise agility; impact mapping is a way of mapping any goal using four ordered questions why, who, how and what. Why is the most important aspect; in the case of the need to be agile, answering "Why do we aspire to be Agile" properly and keeping these reasons in the forefront of the discussion invites teams into agility instead of imposing it on them. However, in most mandated enterprise agile transformation the conversation focuses on the who, how and what.  Often you would hear organizations or senior management wanting to be agile so that they can deliver faster and cheaper.

The Transformation Problem

Starting without the why of agile transformation results in moving the focus away from the people aspects of agility; mindset, culture and values get put on out of sight. Business transformation "experts, who know surprisingly little about organizational dynamics and the psychology of change." become involved in implementing agile, as Maurice Hagar put it in his article. Unfortunately, many of these consultants also know very little about agile or agility beyond the frameworks and ceremonies. They are often not invested into the agile manifesto (the values and principles). Which means they don’t see agile as a culture or a mindset, rather they see it as a mere collection of processes and practices.

As a result, the transformation is shaped around the "how"; the processes, practices and frameworks. Such transformation is a linear, step-by-step change program because processes can be implemented, practices and methodologies can be adopted and "resources" (they mean people) can be trained. What we get at best out of these transformations are cargo-cult agile teams and organization. (I have seen "experienced" agile organizations who were confident that they had been "doing agile for years" just because they buy post-it notes in bulk and plaster the wall with them.)

Many of these consultants are invested in a framework or a methodology; they approach the change with a prescriptive solution in mind. As a result, they come with Diagnostic Organization Development approaches and practices and consistently and continuously impose frameworks, processes and practices on the teams with little empathy or respect for the people whose lives they are impacting. Mike Burrows discusses the 2 OD school of thought here

The "who"

I covered the first problem of "who" in the context of the transformation consultancies approach to agile adoption as a linear step-by-step change program focused on processes and practices. Transformation success factors are focused on checklists of binary states around processes and practices and related roles; "Does each team have a Scrum Master?", "Does your team do stand-up?" so on and so forth. The "who" challenge actually gets worse with certifications and 2-day courses that produce "certified" agile "masters". So, what we have is a money-making industry mass-producing certified "agile masters" into a world of time-constrained/high-pressured enterprise transformations obsessed with processes and practices with a goal of making everyone and everything agile by following a set of rituals. The result?  People who claim the "Agile manifesto is not that important" or an agile coach who explains that "a scrum master is basically an agile version of a project manager". These are the people who interact with a lot of the new domains that agile is being adopted into, with faux-agile so ingrained in their mindset that unlearning is becoming really difficult.

Where do we go from here?

There is no doubt that we are in a critical juncture in the agile adoption journey. However, Agile is not dead, Agile is alive; agile is not done growing yet (dead things don’t grow). What we are going through is a by-product of that growth. And as a result, Agile has probably been hijacked too. To draw some positive and pragmatic inspiration from Simon Kirk:

"I don't disagree with the premise that a lot of what's being done now under the name of "agile" is anything but. On the other hand, I truly think that this stage is an inevitable step along the road of wider adoption of agile (by which I mean properly done agile, by the way)."

We will probably continue to face these and other challenges in the form of Dark/Faux agile. While acknowledging that, we also need to take a stand against dark/faux agile. And one thing for sure we can’t afford to do is to walk away. The agile community and Agilists need to agree not to give up on agility; us giving up would create a vacuum that can be easily be filled by individuals who do not value the agile manifesto beyond the frameworks and practices.  There are a few things that can be done to start this stand.

Back to the basics and beyond

One quick thing for us to do is to shift the focus away from the practices, processes and methodologies/frameworks.  I am not proposing the abandonment of practices, processes and frameworks; I am not saying they don’t matter either. I am reminding you that they are just stepping steps towards true agility (mindset), and they are ways we manifest that mindset.

I mean there is nothing wrong with having a discussion or coaching session about anti-patterns of your teams’ ceremony, the problem comes when those conversations are not brought back to the basics of the agile philosophy.  Think about the concerns the scrum masters display when the team’s stand-ups are beyond 15 minutes vs. the concerns when their team’s response to "why do you have a stand-up" is "because we are agile". We should not only stop at the manifesto, rather frequently and continuously invite discussions, coaching sessions and reflections on mindset; on behaviours and cultures that manifest that mindset. (Thanks to Ahmed Sidky)

We should start the change with ourselves. We need to constantly remind ourselves of what is important. We value people over processes and tools, and our dialogue should exhibit that.

Making alliance

As one of my change management colleagues puts it: "Agilists can be very protective of their ground" – I know I am guilty of that and I believe a lot of us are. Maurice made a beautiful analogy in his article where he compared Agilists setting sail for new lands/domains such as Human Resources.  I believe we are at the place and time where Expansionism is unnecessary and could be fatal. We need to create an alliance with the humane areas of knowledge. Let me try to establish a very quick relationship:

  • Agility is a and state of being; there is much to be learnt from psychology.
  • Agile means a change in mindset; we need to apply the likes of Transtheoretical model
  • Enterprise Agility requires a change in people and organization; we need help from  organisational development and change management professionals.
  • Enterprise adoption of agility will change way individuals, their surroundings (organization structure) and the way they interact with the environment (behaviours) – we need help from Organizational Psychologists.

(Disclaimer: Please don’t get the idea of spinning up 3 days Certified Agile Organisational Psychotherapy (CAOP) certification).

I am sure we can add many more to this list.  The potential for learning, exchanging and growth is immense.  The alliance itself can be dynamic and I am sure will take many shapes going forward; expanding from sharing knowledge to complete immersion in various domains.

Leadership

Many of my Coaching colleagues find leadership coaching and/or engagement disagreeable; maybe there is not enough excitement in that space, which unfortunately creates a vacuum. We need to change this; while we are working on the agile funnel and working towards shifting the focus to the left, we need to make sure we bring the leadership on the journey; there are two aspects of the impacts that agile leadership brings about.

The first is bringing change to the agile transformation itself, shifting it from being an imposition to an invitation. This starts with a clear understanding and communication of the "why" of agile transformation.  This brings about human-centric dialogue; culture over methodologies, customer-first approaches and most importantly agility to the agile transformation. The transformation itself becomes an iterative and continuous improvement journey, allowing for growth and learning (and failure).

The other aspect is creating and sustaining the organizational structure that supports agility and an agile culture. Without agile leadership, agility can become a test of resilience and emotional attrition for organizations. Even though enabling people and teams with a set of tools, techniques and frameworks is part of it, this is where more and more leadership awareness and support need to come. What we need is demonstrated servant-leadership and a radically candid culture, starting from the C-level.  A lot of this is enabled by a coaching agreement between the C-level leader and an experienced, empathic Agilist.

The Manifesto

Last, but not least is the Manifesto. I mentioned the need for refocusing dialogue towards the Manifesto that enables an agile mindset. One of our challenges is that the manifesto is a set of principles for "software development". Understandably, many teams cannot internalize the manifesto or connect to this, especially the Principles. What I find surprising is, many Agilists are dogmatic about the sanctity of the 12 Principles. We need to change this and bring the Agile Philosophy and its spirits closer to the heart of the teams we work with. Practices and processes, when guided by the contextualized principles pave the path towards agility.  If the Principles don’t resonate, change them, contextualize them. Philosophy and its spirit are all that matters, not the words. It's only fair to give teams and organizations a set of guiding principles that enables the agile mindset.

About the Author

Mynul Chowdhuri is an independent coach with extensive background in high-impact change programs in various sectors in Australia, New Zealand and India. Mynul helps organizations to adopt to new ways of working at organisational level that improves customer focus, collaboration, relentless improvement and happiness. Mynul is passionate about Business Agility, new-age Leadership, Organizational Psychology and well-being, what he calls Modus Humani (Human Ways). Mynul primarily works with Government Organizations to change the way Agencies provides service to public. Follow him on LinkedIn.

 

Rate this Article

Adoption
Style

BT