At odds?

Share to0

ArticleAgileMay 2012

PM Network

Cobb, Charles G.

How to cite this article:

Cobb, C. G. (2012). At odds? PM Network, 26(5), 26–27.
Reprints and Permissions – opens in a new tab

A large chasm exists between traditional project management perspectives and the newer, agile practices in project management. This article explores how agile and traditional project management approaches can coexist if both sides look past common misconceptions. In doing so, it identifies these three myths: agile is all or nothing; becoming agile only impacts the software development department; and project management principles are at odds with agile. In addition, it provides examples for each myth. The article shows how force fitting a project into either agile or non-agile is a mistake and explores the importance of collaboration. Furthermore, it cites the importance of finding the right balance between planning, control, agility.

VOICES | In the Trenches

By Charles G. Cobb, PMP

I ATTENDED A PRESENTATION at a local agile group last year that contained popular stereotypes, myths and clichés about what project management is. The presenter made a powerful statement: “‘Agile project management’ is an oxymoron.”

I don't agree with that point of view, but it indicates how large a chasm exists today between traditional project management perspectives and newer, more agile approaches. One of the major obstacles to crossing this chasm is the people on both sides who have strong opinions that, in some cases, are based on misconceptions.

Here are a few myths I've come across:

1

AGILE IS ALL OR NOTHING. There are people in the agile community who are so zealous and aggressive about promoting the benefits of a particular agile approach, such as Scrum, that to them it's a black-and-white proposition. Either you fully adopt that particular agile approach and do it completely “by the book,” or you're not agile at all. The truth is, organizations can design a process that blends a plan-driven approach with more agility to fit the nature of their business and projects.

Of course, certain situations call for a traditional plan-driven approach. For example, if you were building a bridge across a river, it wouldn't make sense to say, “We're going to build the first span, see how that comes out and then decide how to complete the remaining spans.”

The mistake many people make is to rigidly force-fit a business or a project to a given approach, either agile or non-agile. The right thing to do is fit the approach to the project, rather than vice-versa. This requires a deeper knowledge of a variety of methods, and an understanding of how to mix and match them as necessary.

2

BECOMING AGILE ONLY IMPACTS THE SOFTWARE DEVELOPMENT DEPARTMENT. Becoming agile requires a broad-based commitment from the business side and the development side, and it may require some major shifts in organizational culture to make it work. If the organization sees the software development process only as IT's responsibility to “make it happen faster, better and cheaper,” and there isn't sufficient commitment from the business side, chances are it will not be successful.

Instead, there needs to be a collaborative approach at a number of different levels. Within the development organization, for example, all functions (development, quality assurance, testing, etc.) need to work together closely to become more agile. Some IT organizations have natural barriers that make it difficult to achieve full collaboration—and there may be situations where that kind of separation is justified.

For example, some organizations preserve a barrier between the development function and the quality assurance and testing function to provide objectivity and maintain checks and balances in the overall development process. But in other situations, separation is a sign of limited organizational maturity.

img

THE MISTAKE MANY PEOPLE MAKE IS TO RIGIDLY FORCE-FIT A BUSINESS OR A PROJECT TO A GIVEN APPROACH, EITHER AGILE OR NON-AGILE.

3

PROJECT MANAGEMENT PRINCIPLES ARE AT ODDS WITH AGILE. In an agile environment, many of the traditional project management principles still are sound even when applied in a different context.

The elements of an agile process might not fall neatly into some of the buckets typical of traditional approaches, such as scope management, time management and cost management. But you still need to find the right balance between planning, control and agility.

For example, the emphasis in quality management used to be on quality control; the role of the quality manager was that of enforcer. In the more contemporary approach, the quality manager plays a broader role of teaching and coaching others to incorporate quality management principles into the way they work. Quality is built into the process by design, and there is less need for enforcement and control.

The modern quality manager takes a broader focus on maximizing the value of a product in satisfying business needs rather than simply controlling the process and eliminating defects. Project managers need to go through a similar transformation. PM

 

img

Charles G. Cobb, PMP, is a senior-level project management consultant and author of Making Sense of Agile Project Management—Balancing Control and Agility. He has been a guest speaker at a number of PMI chapters in the United States.

PM NETWORK MAY 2012 WWW.PMI.ORG
MAY 2012 PM NETWORK

Like what you just read?

Log in or register for a free PMI account to get access 
to even more articles like this one.

Offer from our training partner

Advertisement

Offer from our training partner

Advertisement

Related Content

Offer from our training partner

Advertisement