Agile planning from Juan Banda
Labels
Agile Alliance
(2)
Agile Project Management
(3)
Appearances
(11)
Conferences
(9)
Courses
(2)
culture
(1)
Interviews
(2)
Management 3.0
(1)
NVC
(1)
Podcast
(1)
Presentations
(8)
scrum
(38)
Scrum Cafe
(1)
Thursday, August 16, 2012
Wednesday, August 1, 2012
PMP®s vs Agile Project Managers: Clash of the Titans
Introduction
To
the casual observer, a PMP® is in one corner and in the opposite corner
we have an Agile Project Manager. This seems to be the situation
because both advocate different visions of how to run a project, and
even different concepts about what a project really is. The PMBOK® has
been mainstream for years in project management, but in the last decade
Agile gained more popularity and now seems to be ready to challenge
the champion for the belt. But is it really true that these two are
opposed, or would it be possible to find common ground? Don’t miss this
fight that 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 constraints are evaluated, measured and specially controlled.
Reactions to risks are not spontaneous, but rather come from a risk
plan already elaborated. The principle does not sound bad and it has
worked very well in various engineering fields. Proof of this are the
bridges, pipelines and refineries built under the wise leadership of
notable PMP®s.
But, and here is the big but, what happens when you cannot plan everything at the start or when the plan is too costly to maintain? Or what happens when you cannot know all the scope in advance? A PMP® 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 does not sound too bad either but who will be responsible for hiring, performance evaluations, procurement, contracts, budgets and other "insignificant" project matters?
But, and here is the big but, what happens when you cannot plan everything at the start or when the plan is too costly to maintain? Or what happens when you cannot know all the scope in advance? A PMP® 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 does not sound too bad either but who will be responsible for hiring, performance evaluations, procurement, contracts, budgets and other "insignificant" project matters?
Round 1 – PMP®s Attacking
Having
competing constraints under control and identifying all risk in a
project is definitely not a bad thing to have. 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 another great thing to have. All this is not utopia, it
actually happens in many large projects with large number of resources
attached.
C-level executives making informed decisions based on solid data professionally compiled, analyzed and presented by capable PMP®s is also not utopia. For instance, oil and construction companies around the world have reported very 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.
C-level executives making informed decisions based on solid data professionally compiled, analyzed and presented by capable PMP®s is also not utopia. For instance, oil and construction companies around the world have reported very 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 Defending and Counter-Attacking
PMP®s
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 the PMBOK®
process.
Agile Project Managers do a great job cultivating their teams and fostering communication and Agile values. They play a vital role helping their teams and organizations to transform to Agile. Things become tricky though when Agile organizations become bigger and bigger and more projects are added and team members are counted by dozens. Project areas like procurement or staffing, for instance, are not likely to be attended to by an empowered developer.
It can be inferred then that, even though Agile values and principles live in an organization and Scrum found a home in the heart and soul of team members, still someone needs to take care of some other project aspects.
Agile Project Managers do a great job cultivating their teams and fostering communication and Agile values. They play a vital role helping their teams and organizations to transform to Agile. Things become tricky though when Agile organizations become bigger and bigger and more projects are added and team members are counted by dozens. Project areas like procurement or staffing, for instance, are not likely to be attended to by an empowered developer.
It can be inferred then that, even though Agile values and principles live in an organization and Scrum found a home in the heart and soul of team members, still someone needs to take care of some other project aspects.
Round 3 – Locking for the Knockout Punch
Successful
PMP®s with years of experience managing multi-million dollar projects
can be driven crazy by the all-the-time-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 seems to be the only way
to cope with the changing requirements. But are the PMP® mindsets
ready for these?
By the same token, PMP®s tend to look at 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.
The knockout punch from the PMP side tries to come from the side of prescription and emphasis in planning, monitoring and specially controlling.
In the other corner Agile Project Managers believe in the values and principles that they help their teams to cultivate. These values in time help team members to interact in such a way that a positive synergy is created. Still, some important areas of a project are running unattended because projects are not just about team members, technology and client’s requirements.
Scrum as a framework was not thought out as a complete instrument for attending to 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 like watching the budget are things that cannot be ignored for the sake of keeping Scrum pure in its form.
The Agile side attacks back with a knockout punch that in reality is no punch but Agility to dodge punches and throw debilitating small punches.
By the same token, PMP®s tend to look at 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.
The knockout punch from the PMP side tries to come from the side of prescription and emphasis in planning, monitoring and specially controlling.
In the other corner Agile Project Managers believe in the values and principles that they help their teams to cultivate. These values in time help team members to interact in such a way that a positive synergy is created. Still, some important areas of a project are running unattended because projects are not just about team members, technology and client’s requirements.
Scrum as a framework was not thought out as a complete instrument for attending to 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 like watching the budget are things that cannot be ignored for the sake of keeping Scrum pure in its form.
The Agile side attacks back with a knockout punch that in reality is no punch but 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 PMP®s fail to understand that Scrum as a framework is not about process and mechanics, but about values and mindset. This failure in understanding usually causes dysfunction and suboptimal results, if not complete project failure, in the attempt to adopt Scrum. The problem again seems to be in the oversimplified vision of a project that can be conceived-of only as a collection of processes and plans. Planning is indeed an important aspect of Scrum, but inspection & adaption, transparency, values and especially people are considered more important.
Agile Project Managers should also consider that they still need to somehow manage some portions of the projects, not necessarily people but processes to keep the project running. Not paying attention to anything but the team and Agile could create a bubble that might burst at any moment.
PMP®s can become Agile Project Managers, but this is not simply a matter of changing titles. A deeper transformation is required. As this transformation occurs, no one says that a PMP® needs to forget about the processes required to support the project. It is just that their mindset needs to be open enough to find the right balance. Needless to say, the command-and-control mentality has to go away to be replaced by openness and a trust-the-team mentality. That mentality has to transform, but the PMP®s’ other skills can still find their uses to support projects, as “adapters” to effectively interface between teams and the bigger organization.
Agile Project Managers can also take the time and energy to learn about the PMBOK®. There’s Agility there if we look carefully and with a very receptive mind.
One Japanese proverb says that “there is no small opponent, only small thinking” and small thinking is what might lead us to think that either PMP®s or Agile Project Managers have discovered the silver bullet approach for project management. Both approaches have something to contribute if rivals are ready to hear the other side and add the other’s lessons into their own toolkit.
Frequently enough PMP®s fail to understand that Scrum as a framework is not about process and mechanics, but about values and mindset. This failure in understanding usually causes dysfunction and suboptimal results, if not complete project failure, in the attempt to adopt Scrum. The problem again seems to be in the oversimplified vision of a project that can be conceived-of only as a collection of processes and plans. Planning is indeed an important aspect of Scrum, but inspection & adaption, transparency, values and especially people are considered more important.
Agile Project Managers should also consider that they still need to somehow manage some portions of the projects, not necessarily people but processes to keep the project running. Not paying attention to anything but the team and Agile could create a bubble that might burst at any moment.
PMP®s can become Agile Project Managers, but this is not simply a matter of changing titles. A deeper transformation is required. As this transformation occurs, no one says that a PMP® needs to forget about the processes required to support the project. It is just that their mindset needs to be open enough to find the right balance. Needless to say, the command-and-control mentality has to go away to be replaced by openness and a trust-the-team mentality. That mentality has to transform, but the PMP®s’ other skills can still find their uses to support projects, as “adapters” to effectively interface between teams and the bigger organization.
Agile Project Managers can also take the time and energy to learn about the PMBOK®. There’s Agility there if we look carefully and with a very receptive mind.
One Japanese proverb says that “there is no small opponent, only small thinking” and small thinking is what might lead us to think that either PMP®s or Agile Project Managers have discovered the silver bullet approach for project management. Both approaches have something to contribute if rivals are ready to hear the other side and add the other’s lessons into their own toolkit.
Subscribe to:
Posts (Atom)