More posts by James Lewis
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.