“We’re so agile, even our traditional projects are adopting agile techniques!”
That’s not the punchline of a bad joke; it’s something a rather frustrated project manager said to me a little while ago. He was concerned that his organization was committed to becoming both more “large A” agile in terms of methodology, and more “small a” agile in terms of increases in flexibility and adaptability within the larger project delivery environment. The PM, and his colleagues, were worried there would be no place for them in the organization if it became more agile, and he couldn’t see any indication that agile expansion was slowing down.
I can understand this project manager’s concerns; he is witnessing the rapid expansion of a project delivery approach he has few skills in and little experience with. He and his colleagues found it easy to ignore—or perhaps even ridicule—agile when it was first introduced. Now that it is gaining traction, he fears they are viewed as unable or unwilling to be part of the process.
At the same time, the organization’s traditional project delivery techniques are evolving to embrace concepts like requirements uncertainty, increased amounts of project team-driven change and less robust focus on the triple constraint. It’s easy to see the source of worry; but with respect to this project manager, I think he’s asking the wrong questions. To understand the agile expansion that is occurring in his organization, he needs to look not at methodology, but at drivers.
When agile as a concept began, the idea was to focus work effort on delivering meaningful results for clients—changing the approach to work to put the customer (and in particular the product being delivered to that customer) front and center. It wasn’t about ignoring requirements or avoiding structure, and it certainly wasn’t about eliminating project managers—it was just about delivering a better solution, ideally (but not necessarily) in a shorter timeframe and for less cost.
The reason agile then grew so rapidly was because it worked. When implemented well it delivered better solutions, which resulted in greater customer value—and, in turn, greater business value. Sure, the teams involved in agile generally preferred working in that model, but that’s not why it became popular. The expansion generally started within software development, then in other areas of IT and then gradually into other business areas.
While agile certainly isn’t a silver bullet, it has consistently demonstrated that it can deliver similar successes in many different areas of the business. That has led to not only continued expansion, but also the embedding of agile as a mainstream approach for increasingly complex and business-critical initiatives.
It helps that there are a large number of project types that can be delivered with agile. As a result, there is often the ability for the organization to choose between both agile and traditional for a particular initiative. However, that decision—to use agile rather than a traditional waterfall approach—isn’t because of personal or organizational favoritism; it’s because of results.
Separate from the growth of agile as a methodology, but certainly in parallel, most organizations are finding themselves in a much faster-paced operating environment than a few years ago. This is the result of the technology-enabled growth of the global economy, the lowering of barriers to entry (also technology enabled) in many industries, and the ever-evolving demands of clients for new and improved solutions for virtually every element of daily life (directly and indirectly related to technology).
In order to survive in this environment, organizations have turned to agile methodologies to help ensure there are no gaps between customer demands and delivered products, and perhaps to facilitate faster delivery. However, those same organizations have also recognized that project delivery alone will not allow them to succeed. They need to evolve investment planning, portfolio management, the ability to absorb and adapt to change, and the focus on optimizing performance against business goals.
That’s what’s driving the “small a” agile part of the organization’s evolution—and it’s what is causing the project manager to feel as though his traditional projects are becoming agile because of the changes that are occurring. As the organization seeks to enhance its ability to respond to threats and opportunities in its environment, it is shortening the planning cycle at the leadership level. That results in fewer programs as approvals are sequenced rather than giving the go-ahead up front for a major initiative.
For the same reason, larger projects are more commonly being broken into a number of smaller initiatives. This is also leading to less predictability—both in terms of which project the PM or team will be working on in a few months, and also in terms of the constraints they will be working to in a few days or weeks
In order to effectively deliver projects using more traditional methods, organizations are introducing agility into the project approach. They are empowering teams to drive change when required, removing some of the formal control and oversight and encouraging project managers to work with their teams to embrace less certainty in the planned work.
This is what the project manager I mentioned is perceiving as the start of the process of converting all projects to agile; but in reality, it is a necessary adaptation to ensure those projects that are better served using a traditional approach can deliver optimal results. In other words, the changes are being made to ensure the organization retains the ability to deliver using agile or waterfall methodologies.
This is the irony of the situation. The organization recognizes it has an advantage if it has two distinct project delivery approaches to choose from—it helps ensure it can always choose the right one for the job. However, to retain the relevance of waterfall, it is making some adjustments that are causing existing project managers to feel threatened.
Not all organizations are created equal
This evolution is not something that is happening in all organizations and all business areas. I know of many organizations—commonly very large companies in very traditional industries—where agile is still restricted to a relatively small group within technology. For the project executives in traditional project delivery areas, waterfall is still the only approach in use—and it has changed little in the last 20 years. There is commonly an expectation that it will change little in the next 20 years because agile is something that happens elsewhere.
I understand that perspective, but it’s shortsighted. Twenty years ago, agile didn’t exist as a formal concept; and 20 years ago, the technology-driven world we live in was a vastly different place. Twenty years from now, who knows what kind of change we will have seen. But I strongly believe that traditional project approaches will need to evolve if they are to be optimally successful.
That doesn’t mean they won’t exist; I believe they will. But it does mean they will need to evolve and embrace elements of “small a” agility in response to the need for all organizations to become more responsive to threats and opportunities.
Agile never stops, but the definition broadens
So to bring us back to the question at the beginning: When does agile expansion stop? For most organizations, the answer is it never does. However, everyone—agile practitioner, traditional project team member, executive, etc.—needs to recognize that they must expand their perception of what constitutes agile. It isn’t simply a product development approach; it’s an evolving mindset that will change how organizations operate. Agile will allow organizations to become more responsive to threats and opportunities, it will allow them to focus efforts and energy on work that actually drives results, and it will enable improved alignment between work and the business benefits delivered by that work.
Agile will evolve to the point where it is simply part of the way an organization does business, just as collaboration is today. Just as with collaboration, there will be those that do it well and those that don’t; but it will cease to be simply a project delivery approach and evolve to become a business approach. Agile project delivery methodologies will still be important, but only as a mechanism to help deliver enterprise agility as a larger concept.
Let’s end this where we started it, with the project manager who was concerned he would soon be out of work. If he views the evolution of his style of project management—to be more responsive to change, more aligned with business needs and more able to adapt to changes in those needs— as negatives, then he will indeed soon be unemployed. However, that’s not because of the expansion of agile project delivery, it’s because he is failing to recognize that his function is to deliver better project performance—and that performance is measured in terms of delivering value.
Stevbros delivers project management training worldwide, our courses have proven their worldwide acceptance and reputation by being the choice of project management professionals in 168 countries.