PMPs versus Agile Project Managers: Clash of the Titans

October 22, 2012 in Roles

6 13

To the foreign eye, a PMP is in one corner, and in the opposite corner we have an Agile project manager. This seems to be so because each advocates a different vision of how to run a project, and even a different conception about what a project really is. The PMBok Guide has been the source for years in project management, but in the last decade Agile has gained more popularity and now seems ready to challenge the champion for the belt. But is it really true that this two are opposed, or it would be possible to find common ground? Don't miss this fight, which doesn't promise knockouts but instead may go the distance.

Introducing the opponents For a PMP, a project is basically control and detail planning: "Plan the work and work the plan." Schedule, resources, risks, and other competing constrains are evaluated, measured, and specially controlled. Reactions to risks are not spontaneous but rather come from an already elaborated risk plan. The principle doesn't sound bad and it has worked well in various engineering fields; proof of this are the bridges, pipelines, and refineries built under the wise leadership of notable PMPs. But and here is the big but what happens when you can't plan everything from start, or when the plan is too costly to maintain? Or when you can't know the project's scope in advance? A PMP's simple answer would be, "For that we have rolling-wave planning, and that's Agile enough." On the other side of the ring we have the Agile prophets who say that they can lead complex projects with values, post-its, and, especially, empowering people. That doesn't sound too bad either, but who would be responsible for hiring, performance evaluations, procurement, contracts, budgets, and other "insignificant" project matters?

Round 1: PMPs attack

Having competing constrains under control and identifying all the risks in a project is definitely not bad; even knowing in advance the scope and freezing it would be a perfect thing in a project. Monitoring a project based on simple indicators that provide solid data is also great. All this is not utopia; it actually happens in many large projects with a large number of resources attached. Executives making informed decision based on solid data professionally compiled, analyzed, and presented by capable PMPs are also not utopia. For instance, oil and construction companies around the world have reported successful experiences by running projects following the guidelines described on the PMBok framework. Still, something seems not to be adding up. Oil and construction projects are large and complicated but not necessarily complex in nature. Software development projects, on the other hand, belong to a much more complex knowledge domain.

Round 2: Agile project managers defend and counterattack PMPs around the world recognize that one key factor in all projects is communication, and here is where Scrum, with its team-centric approach, has something better to offer. Tackling complex problems with empowered teams thinking creatively seems not have a rival in thePMBok process. Agile project managers do a great job cultivating their teams and fostering communication and Agile values. They play a vital role in helping their teams and organizations transform to Agile. Things become tricky, though, when Agile organizations become bigger and bigger, more projects are added, and team members are counted by the dozens. Project areas such as procurement or staffing, for instance, are not likely to be attended by an empowered developer. It can be inferred, then, that even though Agile values and principles live in an organization and Scrum has found a home in the heart and soul of team members, someone still needs to take care of some other aspects of the project.

Round 3: Looking for the knockout punch Successful PMPs with years of experience managing multimillion-dollar projects can go crazy in the ever-changing-requirements environment of an IT project. Of course, a prescriptive approach like creating all the plans that the PMBok recommends can be taken, but this approach is doomed to fail due to the complex nature of software

development projects. Adaptability and Agility seem to be the only way to cope with the changing requirements. But is the PMP mind-set ready for this? By the same token, PMPs tend to look to communication as a process that can be formalized, monitored, and even regulated. In a complex knowledge domain, teams are cultivated and communication occurs spontaneously, with no barriers or hierarchies to prevent it. Still, the knockout punch from this side tries to come from prescription and emphasis in planning, monitoring, and controlling. In the other corner, Agile project managers believe in values and principles that they help their teams cultivate. These values, in time, help team members interact in such a way that a positive synergy is created. Even so, some important areas of a project run unattended because projects are not only about team members, technology, and client's requirements. Scrum as a framework had not been thought of as a complete instrument for attending all project aspects. As light a framework as it is, Scrum is not equipped to deal with project aspects that require interfacing with other areas of the organization, client organization, or third-party organizations. Crucial aspects such as watching the budget are things that cannot be ignored for the sake of keeping Scrum pure in its form. This other side attacks back with a knockout punch that in reality is no punch but the Agility to dodge punches and throw debilitating small punches.

Going the distance Good project managers on both sides need to recognize that the selected framework is just the vehicle for the ultimate goal of having a successful project at four levels: commercial, financial, technical, and personal. Frequently enough, PMPs fail to understand that Scrum as a framework is not about process and mechanics but about values and mind-set. This failure in understanding usually causes dysfunction and suboptimal results, if not complete failure, in the attempt to adopt Scrum. The problem again seems to be in the oversimplified vision of a project that can be conceived only as a collection of processes and plans. Planning is indeed an important aspect of Scrum, but inspection and adaption, transparency, values, and especially people are considered more important. Agile project managers should also consider that somehow they still need to manage portions of the projects that aren't people but processes, processes that are necessary

to keep the project running. Not minding anything but the team and Agile principles can create a bubble that could burst at any moment. PMPs can become Agile project managers, but this is not a matter of changing titles: A deeper transformation is required. If this transformation occurs, no one says that a PMP needs to forget about the processes required to support the project, it's only that their mind-set needs to be open enough to find the right balance. Needless to say, the command-and-control approach has to be replaced for openness and a trust-the-team kind of mentality. That said, a PMP's other skills can find their place in supporting projects so that they effectively interface between teams and with the bigger organization. Agile project managers, meanwhile, can take the time and energy to learn about PMBok. There's Agility there if we look carefully and with a receptive mind. A Japanese proverb says that "there is no small opponent, only small thinking." Small thinking is what might lead us to believe that either PMPs or Agile project managers have discovered a silver-bullet approach to project management. In fact, both approaches have something to contribute if the rivals are ready to listen to each other and add the other's lessons to their own tool kits.