Is Agile The Answer?

At a fundamental level, one aspect of being “Agile” means that your team or enterprise is organized to be able to respond quickly and smoothly to the realities of changing business dynamics and priorities. Given this reality, absolutely yes, the practice of Agile is the answer, because our world is not wholly predictable.

At a project level, the frequency at which a tradition “Waterfall” organization puts products in front of users results in feedback cycles that are too long to be effective. Risk of failure is increased enormously the wider the gulf between problem definition and solution delivery. I know well the feeling of security that a well-constructed Gantt chart can bring at the outset of an initiative, but experience has taught me that this security is an illusion.

From an organizational perspective, an Agile approach increases collaboration between team members as well as between teams, and demands greater involvement from all team members when it comes to decision-making with respect to project direction. Contemporary management literature is almost singularly aligned in its focus on the need to develop “autonomy” at individual and team levels. A collaborative Agile approach to project delivery is the best opportunity we have available to us now to realize the benefits of this autonomy, and the best framework by which to develop it.

You may have heard in recent months about the “death” of Agile. Examples of this kind of thinking can be found on popular sites such as Infoq, MindtheProduct and TechBeacon. I say nuts to this idea. Different flavours of branded Agile approaches such as Scrum, Kanban, SAFe, etc., may come and go and rise and fall in popularity. These approaches are also intended for certain situations, so not a single one will ever necessarily be in vogue at all times. When I’m talking about Agile, generically I’m talking about the Agile mindset:

  • the realization that we do not know what we don’t know
  • that planning in great detail long before we embark on a project is often wasted effort and time that could have been spent implementing
  • the best way to reach a successful outcome is by learning and readjusting our approach based on the all-important feedback loop.

Transitioning to an Agile mindset and approach is by no means simple.  Agile is pragmatic, so there is a lot of work involved, including redesigning projects and team structures, coaching collaborative behaviours, and developing proper ceremonies. Far too often this work is not approached seriously enough, resulting in some form of either putting everyone in one room or setting up a stand-up being considered enough to make Agile “happen”. As time comes and goes and the Agile mindset doesn’t develop, and the benefits don’t materialize, it is Agile that is usually blamed. Agile is not a one-size-fits-all solution. There is definitely a difference between what Agile promises and its individual implementations, and it’s important not to become confused between the two.

When I started working in an Agile way almost five years ago, it quickly became apparent that what Agile really represents is a capitulation to reality. What we have at the outset of any initiative are the objectives we want to satisfy, and some broadly drawn ideas about how to start meeting those objectives. What we don’t have is a precise understanding of everything we will need to do to satisfy our objectives, how long each of those things will take, and who will do them. Reality always intervenes, and if you’re not ready, it can be painful. Being Agile means being mentally and organizationally prepared to respond to reality when it deviates from our ideal visualization. Not working in Agile means continuing to pretend that this isn’t how things really work, and that the journey of a software project always follows a straight and predictable path. The answer is clear. The choice is up to you.

It's only fair to share...
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin

1 thought on “Is Agile The Answer?

  1. Gordon Wallace
    Gordon Wallace

    Thank you for the erudite article, James.

    A few years ago I enjoyed a talk by James Snowden describing his decision-making framework Cynefin. He asserts that most software projects are chaotic in nature, characterized by the presence of unknown unknowns, as you point out. Planning doesn’t work because you don’t know what to plan for, in which case the recommended approach is to do *something*, see what happens, and respond to the outcome. “Move fast and break things” …Then fix them, of course. I believe this is the key innovation of the Agile approach for managers to understand. On the development side, the concept begets continuous integration, where the feedback cycle is reduced to one day (max): trunk-based development where every developer works to ensure new code plays nice with the existing system and that of others every day. This demands a robust automated testing strategy, which should be created anyway, and acceptance that “breaking the build” is good because it means a test worked and exposed information that can be acted upon. I’ve found these latter ideas to be a tough sell with many development teams who fear failure and can’t let go of some branching strategy like GitFlow, for example. But you said it best:

    Reality always intervenes, and if you’re not ready, it can be painful. Being Agile means being mentally and organizationally prepared to respond to reality when it deviates from our ideal visualization. Not working in Agile means continuing to pretend that this isn’t how things really work…

    The inevitable merge-from-hell is reality intervening, and coding in silos (branches) is pretending that this isn’t how things really work. I hope more development teams will extend the ideas you put forth here to their everyday development work by embracing continuous integration and relegating branch-based schemes such as GitFlow to the past.

Leave a Reply