Agile approaches are enjoying a bit of a field day right now. Whether we think about agile solely in the context of project management, or in how we develop software, you cannot go to a conference, attend a presentation or have a discussion about projects without someone bringing it up. And usually, the question starts with “how is that different in an agile project.”
There’s a fascinating implicit assumption in there: agile has to be different. And it’s something that I hear over and over again. I give very few presentations in the project management field that don’t end with at least one question—and often many more—that essentially asks how agile is different.
We have to start any answer with a follow up question, which is, “Different than what?” Usually, it’s about “different than waterfall.” Occasionally, it might be about “different than traditional approaches.” Every once in a while, it’s about “traditional project management.”
There is an interesting paradox built into all of that, because agile project management and agile development practices have become almost inseparable. When we are talking about “agile,” we are usually talking about “agile software development.” The odd example explores a different industry or project type, but it’s rare. After many years of trying to separate the ideas of management approach and development methodology, we find ourselves trying to weld them back together again.
At the same time, though, all those questions highlight the attempt to cleave agile approaches from everything that came before. There’s a feeling of “agile is different and shiny and new and awesome.” Where, by comparison, everything that came before it is perceived as dull and grey and valueless.
Except that was never the intent. The origins of agile were a response to the management—and more importantly, the development—practices of the day. In particular, they were in reaction to what was seen as too formal, bureaucratic and administratively heavy approaches to building software. The agile manifesto started with four values, all framed as “we value this over this.” This was a wonderful way of declaring what was important for the people in the room. But the manifesto includes one other very important, and often overlooked, statement: “That is, while there is value in the items on the right, we value the items on the left more.”
Every idea in the manifesto was important. Plans were important. Contract negotiations were important. Documentation was important. Processes and tools were important. The concern expressed by the authors of the manifesto was that they were being valued too strongly, though, and that other values were being discounted. Individuals and interactions also have value. Collaboration has value. Change has value. Working software, in particular, also has value. The original authors were looking for a way to shift the balance in a different direction.
Unquestionably, shifts have been occurring. Agile has grown. Projects and teams are adopting it, and more are considering, trying and experimenting with it. At the same time, agile is incredibly new. New enough that the attempts to define it and make it work are still framed as “how is it different?” And very often a follow-on sentiment of “how do we make sure it is different?”
This got highlighted for me a couple of weeks ago, with a comment on a presentation that I had delivered. The presentation was an exploration of the future of the project management office. It explored several scenarios, based upon the influences, forces and uncertainties that exist within project management and the organizations that practice it.
The particular comment was, “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.”
That comment raises a host of issues for me (as you can undoubtedly tell, because I’ve chosen to dedicate an entire post to responding to it).
The first—and easiest to dispatch—is the idea that a PMO for waterfall projects implicitly has to be different than a PMO for agile projects. It does not, necessarily. It might be different. And there are many instances that would make it absolutely no different whatsoever. PMOs get created for many purposes. They can be responsible for oversight, for training, for championing practices, for celebrating successes, for reporting and for actually managing delivery of the project. The structure fundamentally serves the purpose. If the purpose is the same, the structure will likely be remarkably similar.
Project management offices also don’t get built around the projects they support. They get built around the organizations that they support. First and foremost, PMOs are an organizational entity. Creating a PMO involves the formulation of a unit whose functions used to exist—often in a diffuse and informal way—throughout the organization. Responsibility, accountability and power are now conferred in the PMO, where they used to occur somewhere else.
This is one of the reasons that the creation of PMOs is challenging (the average life expectancy of a PMO is still about two years). They were born with a target on their back, and the resentment of all who perceive they have lost power, influence, discretion or the ability to just go off and do what they please with minimal oversight or constraint. And PMOs don’t help themselves when they aren’t clear about their role, their value or how to deliver their services.
But that sentiment sits at the intersection of an important concept about agile, as well. And it’s one we lose sight of at our peril. The way that we set up PMOs—particularly if we are to do it in a way that they stand a chance of success—is in a way that aligns with the culture of the organization. Regardless of what that culture is, the successful PMO will embody—and reflect back to the organization—the values it embraces. The organization that is formal and structured will be supported by a similar PMO. The organization that is fast, nimble and responsive will rely on its PMOs to be the same.
An interesting interview with a number of agile practitioners highlights this particularly well. A panel participant, Ray Arell, pointed out, “If you look at the original people who were there in the room at Snowbird where the Agile Manifesto was written in 2001, they were software engineers. So what comes across are the great values and the things that we need to build great software, but they didn’t have an organizational mindset in the room.”
Arell went on to say, “When we see the word “empowerment,” what does that actually mean? How do I as a director at Intel transfer that to others, when the hierarchy in the organization is often getting in the way of that?” And if we change the term “hierarchy” to “culture,” we get awfully close to the point that I’m making here: there are cultures that agile will align with well, and there are ones where agile will struggle. Agile isn’t just a process; it’s also a mindset. And it is a mindset that doesn’t thrive in the absence of trust, flexibility to be at least moderately risk-taking in nature.
The upshot, for either PMO or agile adoption, is that the wrong mindset for the culture is problematic. Trying to implement agile in a traditional, formal, top-down, extremely hierarchical and command-and-control culture is likely doomed to failure. So is building a PMO that is flexible, responsive and customer service oriented. You might want to. You might see it as the right thing to do, and something that is responsive to failings that exist within the organization. But challenging culture is a difficult and precarious proposition, and one you don’t want to necessarily do alone.
And yes, there are organizations that have responsive and wonderfully customer-service-oriented PMOs. And there are organizations that aren’t just experimenting with agile, but are embracing it firmly—mindset first.
Ulimately, the point remains: culture determines success. Culture is the driving source of my repeated mantra of, “it depends.” Culture leads, and everything else fits in along the way and aligns to it. So what our PMO needs to look like will respond to the culture, and what the culture values. And agile—if it can be successful at all—will do so in an environment that at least acknowledges its worth and relevance, and is prepared to try.
To a certain extent, that’s exactly the challenge that the authors of the agile manifesto faced. They personally valued some things over others. And they were software developers valuing it. In many ways, they were wanting to raise a wall between themselves and the rest of their organizations so they could go off and work that way. With an indulgent manager and a willing enough work team, you might get away with that, at least as a one-off. Keep the team and manager intact, and as long as you deliver, you might even sustain an agile skunkworks for a period of time. But there, you are operating outside—or at least on the fringes of—the organization.
As I’ve already stated, PMOs are organizational instruments first and foremost. So the only way that you are going to get an agile-oriented PMO is in a culture that actually values the principles that govern how agile projects work. That value is going to be evidenced in attitude, in approach, in philosophy and in mindset. Which is not to say that its structure may be any different than the PMO at the organization down the road.
The box I fill on the org chart is the product of structure. The attitude I bring to occupying that box is the product of culture—mine and the organizations. The process that I am using and the structure that I am occupying influences that far less. Culture is everything. It is culture that will determine whether, ultimately, agile will sink or swim.