Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

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?

  • BaSche

    Agile can’t make you a good coffee. That is definitly a big shortcoming of agile. But it is still good at forming a team that works towards a moving target. Build Software, try different approaches and learn as much as you can, build good systems with or without software. Agile is not a tool to figure out, what a good goal might be but needs to be combined with other things… Start different experiments at the same time (as proposed by Dave Snowden) with teams using agile methods. Use lean-startup-methods to figure out, which goal is next in our experiment…

    Organizaional level -> think Cynefin and start a lot of “Product-Experiments”
    Product level -> go lean to learn what your teams should do
    team-level -> go agile to stay clean and adaptable

    Its not a question of good or bad, but using the right methods on the right scale.

    Just my two cents.

    Cheers,
    Bastian


    Licensed under
Creative Commons License