The Real Divide between Agile Development and Project Management

May 24, 2011

There are a number of polarized views on this subject, but I don't believe that the real argument should be about traditional project management versus Agile development. The PMBOK doesn’t contain evil things, and Agile development doesn’t ignore as much as many traditional project managers might believe that it does. Agile fools you because certain things are implicit.

There are some very good, traditional project managers who don’t understand the hype behind Agile development because they feel that they already incorporate many of the elements that Agile espouses. And they are right. They execute projects as a series of negotiations, viewing scope as negotiable. They take input from teams on estimates and set realistic expectations and deadlines. They run their projects in a highly collaborate manner. They are also in the minority.

Agile development gained a foothold in response to bad project management (and bad management). Poor requirements, unrealistic expectations and deadlines coupled with demands of excessive overtime gave rise to the Agile movement. In the process of addressing the problems of delivering software projects, Agile development has rightly challenged the thinking of how knowledge workers are managed.

The divide is in the implementation.

The PMBOK is an excellent body of knowledge, but it is the approach that many companies take that creates a problem. Organizations attempt to capture all knowledge in a process, layering additional control mechanisms into the mix to ensure compliance with the process. This results in an unwieldy, bureaucratic, hierarchal maze of rigidity and complexity. The traditional project management approach becomes one of detailed planning with the objective of organizing and controlling activities to the greatest extent possible in an attempt to guarantee project success.

This creates some undesirable side effects, like inhibiting an organization’s ability to deliver swiftly or to quickly alter course to exploit new opportunities. It also makes it extraordinarily difficult to raise the bar, organizationally-speaking; in fact, it enables organizations to remain average. The thinking and control is already in place, with little to no room for people to take initiative or adapt to unique circumstances.

Not that all “Agile” implementations are exactly on point, either. There are some who want to earn that gold star – but not pay the price for true change. There’s a term for those who adopt the practices, vocabulary, and artifacts of Scrum – mimicking the behavior without really living it. It’s called Cargo Cult Scrum. It’s the mistaken notion that ritualistic actions and artifacts will provide magical benefits.

Agile development is deceptively simple in appearance, but it is a genuine shift in how work is approached and how people are managed. Agile development uses lightweight frameworks and is adaptive in nature.

This requires people to take control of their work, which in turn requires that they develop an understanding of what it really means to own their work and that of the team, to learn how techniques like limiting work in process and collaborating can increase throughput, to explore and use new technical practices to increase productivity – without someone doing it for them. Knowledge is not contained in the process, which means that people must contain knowledge in their heads and take on additional responsibility for their work.

Ultimately, the entire organization is impacted, although many find it easy at first to view “agile” as being strictly for the development organization or as some new project management framework. Once you head down the Agile path, its tentacles will start to reach other areas of your organization and the need for change in other ways will become apparent. Not that getting the rest of the organization to an agile state is a bad thing. Personally, I believe that Business Agility is More Important than Agile Development.

Steve Denning has a great presentation on Making the Entire Organization Agile where he describes five big shifts and how individually, none of the shifts are new. What is new is doing them all at once. And lest we forget, Steve also points out that the real goal for everyone should be in delighting the customer. “Being agile” is not the goal. “Working software” is not the goal. “Making money” is not the goal. “Agile and Scrum and Working Software” are a means to achieving the goal.

Steve notes in the conclusion that many are reaching is that organizational survival in today’s world requires us to manage differently! I agree, but I’m also a believer that one size doesn’t fit all. There needs to be a body of knowledge that addresses what it means to be lean, mean and agile along with tools, techniques, and guidance on what to use and when, taking specific circumstances into account. Those are conversations worth having!