How the "Hybrid" Model Puts Problematic Constraints on Agile Project Management
In a business world preoccupied with concepts like collaboration, accuracy and efficiency, there are trends that don’t, can’t and probably shouldn’t necessarily be applied to all aspects and departments in every industry. Editors, for example, probably shouldn’t be placed in an open-floor office plan beside the sales people - no matter what science says about increased productivity and collaboration in open-concept offices. Similarly, there is a growing trend in project management whereby, to ensure accuracy of reporting and uniformity across reporting structures, project managers are being asked to plan to a template.
That is to say, companies are attempting a “one size fits all” approach to project management, where delivery schedules and milestones match across all projects.
Here’s the problem: projects are defined in the PMBOK as, “a temporary endeavor undertaken to create a unique product, service or result” [emphasis added]. By definition, a project is meant to be distinct from the day-to-day operations of an organization. This, of course, outright clashes with the idea of a template applicable across all projects, but it is accurate. If there’s one thing we’ve learned projects do, it’s change.
I come at this issue with some very recent experience. I was involved in the delivery of an Agile development project using waterfall style deliverables. Sounds amazing and theory – and was really the right way to go given the parameters of the project. Unfortunately, the project was almost immediately handcuffed by the organization’s reporting structure. The organization required all milestones be identified in the initiation phase of the project. Agile projects aren’t delivered that way – they’re build to be flexible, dare I say agile – and, as a result, we couldn’t even get the project off the ground. The reporting structure had no way of accounting for flexible milestones.
The proposed way of marrying Agile project management and waterfall methodology is a kind of “hybrid” methodology. I’ve read a lot of articles on the concept (like this one, and this one) and as appealing as the concept seems, project management requires flexibility. Sometimes, companies need to be flexible to project management, not necessarily the other way around. Remember: it’s not necessarily the whole process that needs to change. Projects are, by definition, temporary. It’s not out of the realm of possibility for reporting to be flexible to a project without a mass overhaul of the entire reporting structure.
The way I see it, dealing with reporting for Agile projects is a bit of an Occam’s Razor scenario. While a company’s ideal may be to fit Agile projects into the pre-existing reporting structure, the entire point of Agile is to move with a project, not to be confined by “external” influences. In this case, the most obvious answer – allowing Agile to work with a reporting structure that is as flexible as the concept itself – is the best answer.
So maybe before we go ahead and throw the baby out with the bathwater and declare Agile ineffective, let’s recognize that waterfall and Agile, while conceivably similar enough to mash together in theory, have different risks and different milestones. As a result, despite the attractiveness of a “one size fits all” methodology, sometimes, the differences are the actual point.
This blog post is brought to you by Scott Savage. You can find him on LinkedIn here.