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

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • A few missing points

    by Andrei Dascalu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would assume you're familiar with Dave Thomas' original "Agile is dead" article as well as (maybe) the GOTO 2014 panel that included Dave Thomas and Martin Fowler about a retake on the Manifesto given the oversaturated market formed around Agile.

    While just about all the points you make are valid, there's still the idea that Agile (capital letter noun) is dead ... and if not, then it should die. All those that signed the Manifesto have (almost) unanimously agreed that it was badly named and the noun-ization of the word (along with the advent of Scrum) helped create the incredible marketing mess we have today.

    There's no "Agile", it's only about having agility in your activity. Starting with your person and going up through the ranks of all levels until the enterprise is able to display it. There are just a couple of principles and maybe a few design rules that can apply not just to development practices but to any activity (from marketing to HR).

    But setting aside the ideas of Fowler and Thomas (very nicely shown in that GOTO 2014 panel), there's another point which I formulated in an anti-Agile and pro-agility workshop I held last year:
    - somehow, the post-Manifesto movement and the Agile-led corruption of the principles somehow created a whole new layer of what most companies consider management (including the "servant-leader" position, conceived in Scrum under the Scrum Master moniker). But if you look at the history of the Manifesto itself you will see that:
    1. the only idea behind its creation was a group of guys writing down the things they were already doing to find out common traits. Scrum and Kanban are the only post-Manifesto 'recipes', but agility was well implemented long before that
    2. all the practices were successfully created and implemented "by developers and for developers" - no management needed. The self managing team was already there without any formalities.
    As Martin Fowler says it best in that GOTO 2014 panel, it all came out of putting together capable developers and letting them find out what works in their particular situations.

    At the moment, armies of Agile scaremongers are bullying companies of all sizes into reshaping themselves according to recipes that are no silver bullets (by their own admission) instead of evaluating whether anything pre-existing actually helps.

  • Re: A few missing points

    by Mynul Chowdhuri,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great points Andrei. Loved the concept "pro-agility". I think I am with you on that, and beyond. It is not only about agility, its about the way we think, the way we are. I feel like a more Humman Way of doing and being.

  • Agile's 10th reincarnation

    by Bas Groot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I am writing a piece that I hope InfoQ will place, about something that's intrinsically wrong about Agile, and relatively easy to fix; it is the root cause why Agile starts to suck after one or two years. Reading your article, I realized my piece should also hook on to the growing choir of voices whispering that Agile is over its peak and it's time for something new. I put it as follows:

    Does that mean fixing this flaw is all we need? Well, it repairs the main intrinsic flaw with few changes, that could be implemented relatively quickly. But there's so much more; for example, Agile has turned into a generic cover-up platform for pushing personal agendas and corporate control culture.

    Some even declare Agile dead already [link to your piece]. As long as its upcoming 10th reincarnation acknowledges a) the existence of foreseeable problems, b) the developer mindset, c) the unsustainability of self-steering developer-only teams and d) the value of common sense; then a fresh set of rules, free of baggage, might be a good thing.


    (I am aware that you don't really call it "dead", rather ready for a fresh start)

  • inevitable?

    by Peter Veentjer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Unlike classical CS, isn't it inevitable that every methodology has a limited lifespan?

    Once a methodology becomes commodity, the next step is is to expand it to prevent anyone from mastering it.

    And after some time the methodology has been expanded so much that it suffering from the same problems as the methodology it replaced and it is declared dead.

    Then the time is ripe to introduce a whole new methodology and start from the beginning.

  • Agile isn't dead, its just not a universal solution.

    by Len Porzio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I have lived through Waterfall and Agile methodologies with varying degrees of success on both. Agile, like waterfall, just doesn't always fit the situation.

    The 2 troublesome areas agile faces are customer's who are too busy (or reluctant to participate) and large projects where coordination of resources demand front loaded well thought out interfaces or contractual binding deliveries by one or more parties.

    Sure we can try to dance around large projects and segment them to work via agile but fixing the customer is often not possible and if they don't participate or insist on a big bang solution, waterfall is the better choice.

  • Re: Agile isn't dead, its just not a universal solution.

    by Scott Duncan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You point out two very important issues when considering implementing an agile approach. Bob Martin has a new book coming out where, based on an excerpt I saw, he points out that agile was envisioned for less grand application than is being attempted and has led to so many scaling and larger process models.

  • Agile is a misguided attempt to solve a longstanding problem

    by Stephen F. Heffner,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "Agile as a way of being", "dark/faux agile", "the agile community and Agilists", "practices, processes and frameworks...are just stepping steps towards true agility (mindset)", "anti-patterns", "Agility is a and [sic] state of being", "an agile culture" -- these are all tell-tale signs that "Agile" is basically a religious cult, with no god but the vaunted "agility".

    "Many of these consultants are invested in a framework or a methodology" -- like, say, "Agile"? :) IMHO, "frameworks" and "methodologies" (usually methods with "ology" added for gravitas, BTW, like "technologies" vs. "techniques") are basically attempts to achieve acceptable results from unacceptable people. I'd rather hire good people in the first place; since they know how to develop digital assets properly, they don't need "frameworks" and "methodologies".

    Backlogs? Overdue (or failed!) deployments? Busted budgets? Buggy software? IT-business misalignment? All result from an incompetent and/or arrogant IT environment, not from using the wrong "methodology".

    The idea of applying "Agile" to Enterprise Architecture is doomed to a horrible death. A quality enterprise architecture results from deep up-front design, which "Agile" abhors. And ironically, such an architecture is inherently agile (lower-case "a") because it's rationalized, normalized, and optimized to best serve the enterprise's goals and objectives. And EA is an ongoing infrastructure process, not a product creation process.

    "Enterprise Agility requires a change in people and organization" -- why? What about existing people and organizations is so toxic that it must change? My answer -- incompetence, self-centeredness, arrogance, and apathy. No "methodology" can conquer those; only good management and hiring can. IMHO, the level of competence in IT is probably the lowest of any discipline (if you can call it that) in business. The only way to break that is to hire the best and train more of them through education and apprenticeship. Ironically, "Agile" by its nature demands competence in order to survive at all, because when practiced by incompetents it creates massive damage. So it's self-defeating.

    "Enterprise adoption of agility will change way [sic] individuals, their surroundings (organization structure) and the way [sic] they interact with the environment (behaviours)" -- more cult talk. What enterprises need to adopt is quality Enterprise Architecture (see my LinkedIn Pulse articles about EA) and a culture of excellence and professional passion (proper EA helps with that a lot).

    The main thing I like about "Agile" is that it involves stakeholders throughout the SDLC as participants, which also requires that techies be able to explain what they're doing in laymen's terms. But I have practiced that since long before "Agile" was a gleam in anyone's eye.

    When I look at what motivated the original "Agile" movement and where it is now, what I see is a baby that has expired from being tossed out with the bath water. True agility comes from excellent architecture and implementation, not from some "methodology" based on "stories" and "sprints". The dreaded "analysis paralysis" that "Agile" seeks to avoid has always been professional malpractice, not an inevitable result of the equally dreaded "Waterfall" approach (a cartoon version of traditional requirements-driven design and development). It's true that professional malpractice was (and still is) widespread, but the answer is to shape up our discipline and demand excellence in architecture and implementation, not to convince architects and developers to join a religious cult that distorts and damages software development.

    Note that I have put "Agile" in quotes throughout the above. That's necessary because the cult has expropriated and corrupted a very useful English word. The irony is that without the appropriate up-front design that "Agile" abhors, the resulting software is unlikely to be very agile mid- to long-term, unless it was created by competent professionals who didn't really need the cult to do it.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT