How Agile Do We Need To Be?

But how agile is agile? And how agile do we need to be, anyway? And, to be clear about the real question that we should be asking, how unique is agile from what most of us understand project management to be?

Agile project management as a concept has a variety of descriptions and assertions that define what it is intended to represent. Overall, however, it reflects a process that is adaptive, collaborative, based upon an evolving understanding of what the solution that should be produced is–and emphasizes personal interaction and co-operation.

The likely source of agile project management, and much of the perceived value in its adoption, is as a reaction to how projects have been historically observed. It is a backlash against what some consider excessive bureaucracy; formality; rigor and administration; and an attempt to define a management approach that is instead flexible and responsive.

Much of what is being reacted to in promoting and advancing agile project management is reasonable. We have all seen project managers–often newly minted ones with shiny new letters behind their name–who have ideologically held to one process (and only one process), and have done so with astonishing amounts of zeal. We have seen the frustration of dealing with customers and executives that don’t “get” project management, resulting in attempts to make it–and its value–more visible. Certainly, we have seen customers and stakeholders evolve their expectations, wants and needs of their projects, resulting in ever greater attempts to control scope, impose structure, ensure requirements are defined (and agreed to) and control changes at all costs.

The result is a process that looks inflexible, structured and bureaucratic. Certainly, there is no denying that it can be that way. Equally certain, there will be a negative backlash where customers and stakeholders feel that they are advancing reasonable expectations, and sponsors feel that they are defining perfectly realistic constraints. There will also be project managers that try an alternate way of managing, one that tolerates uncertainty and allows for ambiguity and tries to create enough space for change to occur while still utilizing enough management structure to produce a result at the end of the day. That’s the way I have always managed my projects.

Stepping back from some of the more strident viewpoints in the agile community, it also appears to be the foundation for the development of agile management approaches. Even so, “agile” is not a label I feel the need to apply to my approach to managing.

I think that the most important distinction that needs to be made about how we think about managing is that agile is an adverb, not a noun, and a lot of people seem to have forgotten that. Agile is not a thing. It is not a process or a methodology, and it’s certainly not an ideology (although there are those that will tell you that it’s all three and more). Instead, it’s a way of thinking about projects–and particularly software development projects, although the principles can be readily adapted elsewhere–from a different perspective and approach. As a philosophy, it’s not a bad one, and the principles in the Agile Manifesto (which is where much of this debate actually started) actually make a lot of sense.

While the principles of agile come from the software development world, the foundations on which they in turn were based, lay elsewhere–in lean manufacturing, total quality management and the like. Regardless of where they came from, however, principles are principles. They are not rules and processes, and they must be applied with intelligence and consideration to the situation. Here, however, is where my challenges emerge with declaring agile as being unique and separate as a management philosophy. In my view, all methodologies, processes, standards and approaches need to be applied with intelligence and situational awareness. This is not unique to any one approach, but is instead a fundamental requirement for all of them. In point of fact, the ideas of agile are not dissimilar to the application of reasoned common sense.

Of course, this immediately raises the point that much that is common sense isn’t terribly common, but that as much as anything probably proves the point. Those project managers–and, dare I say it, those executives, sponsors and steering committee members as well–who have an appropriate level of wisdom and experience and history of trying to get things done inherently recognize there is no one right way to do things, and that we have to adapt our approaches to the circumstances. Call it agile or call it common sense, but recognize that it is in all cases necessary.

The naming of agile as “agile” and the defining and separating it from other forms of managing is what I find problematic, however, because it promotes the development of ideology and it pits perfectly reasonable approaches against each other in a more subtle variant of the game “my process is better than your process”. In doing so, it potentially does more harm than good. Perhaps it’s necessary to distinguish intelligent adherence to process from those that are subject to blind, knee-jerk conformity.

If that is the point, however, it seems to have been lost in the noise. If we step back and recognize agile as the adverb that it is, it forces a different question from a different perspective. Rather than asking “What is the process I need to follow rigorously here?” it becomes a question of “How do I need to adapt my approach to be successful given the circumstances?”

There are those that will find this problematic. There is a great deal of comfort to be found in the mythical belief that silver bullet solutions do exist. Security exists when we think that if we apply this one technique one way all of the time, then we can be successful. Reality, however, offers another experience. It forces flexibility because the issues, challenges and risks we encounter with one project are not identical to the circumstances of previous ones. There may be commonalities, but there will also be variation. When we live in a world that is subject to dealing with people, politics and uncertainty, adaptation is an essential criterion for success.

The point that it is essential to remember, however, is that agile approaches do not have a unique lock on adaptation or effectively responding to situational experiences. Adaptation is not a product of the process that we use, it’s a product of us and how we apply the processes that we know. It’s not that we need more agile, necessarily. It’s that we do, in fact, need more common sense.

Author: Mark Mullaly, President of Interthink Consulting Inc, Canada. Mark is a popular and engaging speaker who has been invited to address conferences across North America. His widely read column, Project Management in Practice, appears monthly on gantthead, and he is a seasonal instructor in project management with the Faculty of Business at the University of Alberta. Mark is the Past President of the Northern Alberta Chapter of the Project Management Institute.