You're Only as Agile as You Feel

Agile is an approach that, used appropriately, has a lot of promise.

Here’s the thing, though. Any approach, used appropriately, has a lot of promise. Agile is traditionally positioned against waterfall. And there is nothing wrong with waterfall approaches for delivering projects, either.

When you have a clear result, well-defined requirements that will stay well defined, and you know exactly how to get from start to finish, you would be insane not to adopt a waterfall approach. And that is not a remote scenario, by any stretch of the imagination. I work in a linear fashion all the time, despite the fact that the projects that get me excited are the uncertain and complex ones.

But we keep positioning agile as an either/or proposition. And we do that in particular when we think about agile as compared to waterfall. There is an assumption that not only is agile different, but that agile?has?to be different. That it is opposite from traditional approaches. And that for agile to work, it cannot come from a traditional context.

This got driven home for me in a presentation about project management offices that I did a little while ago. A comment came in over the last few weeks that said:

"Another point to think about is the remarkable progress the agile framework is making. PMOs are still largely structured around waterfall projects and I am yet to hear of agile practitioners talking about designing a PMO that is structurally different from the traditional PMO."

There are two implicit assumptions in this statement that need to be called out directly. The first is that PMOs are structured around waterfall projects. Mostly, if we’re honest, PMOs aren’t structured around anything more than the political whims of the day at the time that they were established. They are an organizational structure established to address perceived organizational problems related to how projects are delivered. If most of the projects are being delivered at the time on a waterfall basis, then that’s what it is going to look like the PMO was designed to support.

That leads directly to assumption number two, however. And that assumption is that an agile PMO must, for reasons not elaborated on, be different from the PMO that supports waterfall projects. And that assumption, to be brutally frank, is blatantly false.

That’s not to say that there aren’t a variety of structures that project management offices take on. There most assuredly are. The biggest reason why PMOs have different structures, however, is that they are designed to do different things. There is no one universal definition of what PMOs do, and there is no unified construct of how they are assembled.

PMOs do different things in different organizations. Some are there to police the projects and report on progress, full stop. Others support process development. Some provide training. Some are champions for how projects can and should be delivered. And yet other PMOs are where projects go to get done—they are the home of the project managers, or at least where the large and complex projects get managed from.

The point being that the PMO revolves around the services that are provided, not the types of projects that are supported. I can be an enthusiastic, responsive and service-oriented PMO leader maintaining a project management framework that supports waterfall projects, just as much as I can be to promote agile. The process might be different, but the work I do and the approach I take—and the impact that I have—can be remarkably similar.

What that highlights, though, is a larger problem in how PMOs are perceived. One that points to the issues that I want to explore about just how agile any given organization might be—or can be. When we talk about PMOs, we often talk about structure. And what we don’t talk about is attitude, approach, style or service orientation. And that is a very large problem.

What probably prompted the original comment was that their view that PMOs didn’t feel very agile (again, see previous comments about positioning agile against everything else). What they probably did experience was something that felt bureaucratic, formalized and rigid. That’s not an agile problem, that’s an attitude problem. Or—more specifically—it’s a cultural problem.

There is a sad truth in many organizations that PMOs feel bureaucratic. That they are there to impose structure, to establish constraints and to enforce consistency. And the reality, sadly, is that in many instances, that’s exactly why the PMO has been created. The driver for this is often that the organization itself views itself as bureaucratic, or at least professes a desire to be more formalized and consistent (and the perception of one often leads to the presumption of the other).

What this is reflective of first and foremost is culture. And formal cultures that value consistency and predictability often feel pretty bureaucratic and rigid. Flexibility, adaptability and responsiveness get valued less. This is where agile sometimes perceives itself as encountering difficulty in finding a toe-hold. But this is not a PMO problem, it’s a culture problem.

Culture is the defining force that governs how organizations actually function. It is the enduring, widely understood, not-necessarily-written-down rules of how organizations operate. It is reflective of—and responsive to—the reality of “this is how things get done around here.” And every process, every service and every interaction with that organization is likely to be influenced by that culture.

This means that a bureaucratic and formalized organization is going to make sure i’s are dotted and t’s are crossed. A flexible and responsive organization will make things up as they go along in most interactions, regardless of any precedent to the contrary. A supportive and collaborative culture is going to engage, check in and consult broadly, whether you like it or not.

The kind of culture that you have is what fundamentally influences and shapes the structure and practices of the organization. Regardless of project type, the process employed will be an embodiment of the structure that exists. I’ve seen entrepreneurial and flexible cultures where waterfall projects that should be straightforward and linear are exercises in barely restrained chaos. And I’ve seen organizational adherents of agile that are so rigidly attached to their process and approach—and a belief that if you don’t follow that exactly, then you’re not doing agile “right”—that process adherence often overrides project relevance.

You can argue both approaches are wrong. What is inescapable is that both approaches are a product of their culture. And culture changes glacially, if at all. It can be nudged gently, but it cannot be reprogrammed deliberately (or quickly).

Culture is the shaper of our reality. It also means that culture is the shaper of our projects, and how those projects are delivered. Agile will find more acceptance in a culture that is open to experimentation, adaptation and flexibility. But that’s not to say that more traditional approaches can’t find a welcome home there, as well.

When I manage projects that are linear and well-defined, I don’t leave my service orientation, stakeholder approach or cultural values at the door. I lead with them always. You’re going to get an amazingly responsive waterfall project from me, no different than if I was managing something that was truly emergent and adaptive.

Agility is not about structure, and it is not about process. Agility is about culture. You are as agile as you feel, no matter the process or the project you are delivering. That’s all about the culture you inhabit, and the values you personify.