What Is Agile’s Biggest Shortcoming?

I’m surprised when people think Agile is perfect and if there are any shortcomings, its not the problem with Agile, instead, it is the person/team/org’s understanding or implementation issue. Some where along the way, the aspect that “We are uncovering better ways of developing software” was lost and agile became this static, rule-based prescriptive and dogmatic cargo-cult thing.

IMHO Agile has made a significant difference (some of it a a placebo effect as well) to the software industry however it has some serious limitations when you try to apply in beyond simple CRUD based applications:

  • Agile works well in linear or organised complexity domains where the problem is fairly well understood (static) and we need to find/evolve the solution iteratively and incrementally. But in domains, where:
    • the problem itself is unknown or constantly shifting,
    • the problem has a dozen or so variables that interact non-linearly. For ex:
      • in life sciences where we’re trying to understanding ageing/growth
      • in anti-terrorism where we have to deal with a crisis situation
      • when simulating chaotic systems like Indian traffic system
      • trying to predict outcomes in systems with distributed intelligence

applying agile values, principles and practices is not the best approach in these cases. We often find ourselves lacking the right kind of thought process and tools to be able to manage such project.

  • Event though the Agile luminaries claim that Agile treats software development as a Complex Adaptive System, they actually try to apply techniques that work in a Complicated Domain.
    • For example, given a problem, we analyse the problem, figure our a best-bet solution (set of practices), apply the solution, see what happens, do a retrospective and tweak the solution (inspect and adapt). This is how you work in a complicated domain. In a complex adaptive domain, we try a few independent safe-fail experiments to solve the problem, but most importantly we do all those experiments in parallel (set-based development approach), so we can really amplify good patterns and dampen bad patterns. We manage the emergence of beneficial patterns with attractors within boundaries. Its like running 5 parallel A/B tests and then coming up with a solution.
  • Agile folks seems to claim that distributed development is hard and you should always prefer collocation. But what about thousands of successful open source projects built by people who’ve never met each other? We seem to be missing something here. Open source project model seems to be way better at motivating people by giving them autonomy, master and sense of purpose. Most agile projects are not able to match this.
  • Today velocity and bunch of other vanity metric is killing agility. There seems to be so much focus on output and very little focus on outcome and learning. Agile has very little to offer in the space of customer development, business model validation, User experience and other important aspects required for a successful product launch. Which is what Lean-Startup movement is trying to address. This is clearly a limitation of Agile methods.

What’s your take?


  1. ShriKant Vashishtha

    Based on whatever I have seen so far, in service industry you find people from disparate experience and maturity level. Working with them in distributed setup as a choice boils down to a lot of overheads. In case of open-source teams, I feel every team-member must have basic level of development maturity to work in that fashion. That’s how it works IMHO. It’s similar to “first law of distributed programming”, i.e. “Don’t Distribute” to avoid overheads. I have seen some organizations working in completely distributed fashion (each team member working from different location, country and time-zone). However again in that case as well, it works when team-members are certain level of maturity.

    Regarding Lean Startup and Agile, I still feel that after Customer Development when you need to build MVP, you anyways use Agile principles. Agile is not necessarily Scrum always. Without great engineering practices, i.e. XP one cannot simply work these days. Continuous Deployment and Delivery are important concepts which are backbone for any solutioning team. Business model validation can be extended definition of DONE. Acceptance should not be the acceptance from PO but from validation from the market.

Comments are closed.