When Even Agile Is Considered Overhead

 

This article by Mike Cohn on the Scrum Alliance site, discusses the perception that some people have that Scrum can be a "burden".  This is an often heard complaint I've experienced throughout my PM career whether it pertained to Agile or traditional methods.  Implicit in this argument is the notion of project management in whatever form, method or process as being "overhead" for getting things done.

Now that the profession has matured quite a bit and is established in many industries and organizations, you will hear less of this than in the past, but the perception still holds for some people.  Even in one of the most lightweight PM methods around, namely Scrum, the perception will hold as Cohn states, "these comments have surprised me—Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint. That doesn't seem like much overhead."  While I can agree with this, I can still see why the perception holds and it typically has to do with several core factors.

First, it has to do with the maturity level, or lack thereof in a particular organization.  Scrum and Agile has their roots in software companies, and especially for software start-up companies where the core application or system was developed on the fly by founders loaded up on sugar and caffeine laden sodas and pizzas and all night coding sessions are the norm, even adding a routine of daily meetings and short planned Sprints can seem like overhead.  But at some point, they will need to hire developers and ship a useable product and this is where some planning and process needs to be in place.  Even for more mature or established organizations, there could be a lack of established planning, development and deployment practices where introducing project managment practices can be perceived as overhead.

Directly related to the above is upper managements lack of support for project managment.  And I'm not talking about where an organization experiences chronic delays and overbudget projects and decides to make project management a directive for the organization or department.  As Cohn states, " there's a natural tendency to bristle at any direction given from above. Calling the few generative rules of Scrum 'too much overhead' may be a team's way of expressing displeasure at having any decision pushed down onto them from above."  What I'm talking about is where upper management needs to view project management as a strategic objective of the organization and takes the time to carefully plan, advocate and carry through with implementing project management practices that match their orgainizational's needs and strategic objectives.

Finally, if the project manager or ScrumMaster is not adequately doing his or her job of tracking and managing project details, removing impediments, communication, etc., then their role and the project management role in their organization in general, will be seen as overhead.  But if the project manager or ScrumMaster does an outstanding job, there is no better way in my opinion to sell project management to an organization than when a project manager or ScrumMaster proves this in the flesh.  Though you cannot always control factors such as the maturity of your company or upper management's decisions, you can control how you manage your projects and the manner in which you do so can have dramatic impacts to whether it is perceived as overhead or strategic necessity.