Today's post comes directly from a collaboration between Workfront and Gigaom Research, How to Unlock the Promise of Agile in the Enterprise. In this excerpt, Rich Morrow details the secrets from unlocking the promise of Agile in the enterprise.
It's no secret that the choice of project-management methodology is often the biggest contributor to a project's success or failure. This is especially true in the enterprise where stricter stakeholder oversight is often at odds with team efficiency. The good news is that today, more than ever, all stakeholders—from project managers to management to executives—have access to a wide set of methodologies from which to choose and—especially in larger efforts at larger companies—many of them are often used in concert.
On one end of that spectrum are traditional project management (TPM) approaches such as the Waterfall model, where project features, cost, and schedules are planned out, marched through, and forced back to resolution when they deviate. At the other end is the oft-misunderstood Agile family of methodologies, which are often touted as leaner, faster, and more flexible.
The larger a project becomes, the more likely it will employ a variety of methodologies, leveraging each for its individual strengths where appropriate. A large enterprise software delivery often uses standup meetings, kanban boards, pairing, test-driven development, and delivery sprints in individual teams, then wraps team contributions up into a traditional approach that provides continuity and control.
The choice comes down to picking the right tool for the job, but before we choose tools or methodologies, we need to properly understand them.
The two dominant schools of thought are TPM, embodied in such standards as A Guide to the Project Management Body of Knowledge (PMBOK guide), and Agile project management (APM), which, although originally conceived as a solution for software projects, has since found utility in many other disciplines. Both TPM and APM are umbrella terms that encompass a whole family of concrete methodologies.
TPM is often described as a "top down" or push methodology—management defines the costs, budgets, and schedules, and then addresses deviations from any of them as the project marches toward completion. APM is in many ways TPM's polar opposite, being a "bottom up" or pull methodology—workers self-organize, self-prioritize, and pull what they consider to be the most important tasks from a queue. They can populate it or management can.
Demonizing traditional methods like Waterfall as slow and unresponsive and parading Agile as the cure-all pill for delivery woes is all the rage these days. But, the practice is rarely that simple, and in an organization as complex as today's enterprise, each really has its place. The majority of enterprises use a combination of the two. Before we open that can of worms, though, let's dig a bit more into the specifics of what we mean by "Agile" and "traditional."
Traditional approaches came out of the understanding that certain actions must be completed before other actions. If you're building a house, you first need a permit. Then you proceed with the foundation before you can build the first floor. The first floor must be completed before the second, and installing drywall before the rough plumbing and electrical are finished makes no sense. Organizations like the Project Management Institute (PMI) have produced and managed standards like the PMBOK guide, which lays out general guidance as well as particular methodologies to manage these projects.
Long before the Agile Manifesto was released in 2001, managers of software projects realized that the traditional methods broke down when building software. Software, maybe more than any other discipline, seems to be a moving target in which the end user thinks they tell developers what they want, then the developers run off and believe they built it. Rare is the case when they all get it right on the first go.
The main thrust behind the Agile movement is constant delivery of small, working bits of functionality, ensuring quick feedback and a sort of discovery of requirements as customers and developers continue to tailor and—they hope—improve the product. Agile approaches also allow developers to "fail fast" and quickly prove (or disprove) what will resonate with end customers.
The decision to "go Agile" or not is typically where most project managers start the dizzying process of determining appropriate roles, structure, and reporting. More often than not, however, that is the wrong first step. Before attempting to overlay a project management methodology on a team, a manager needs first to understand how that team currently works. Too frequently, managers fall into the trap of assuming that project-management methodology can be thought of as independent of everything else, when in reality, it's often just a reflection of a company's culture and beliefs.
To read more about the how to make the decision to "go Agile," download the complete How to Unlock the Promise of Agile in the Enterprise white paper.