PMI and Agile Practioners
In my last post, I closed with the following:
The PMI has embraced Agile project management and is the first to admit that by doing so they enrich the entire project manager community of practice. Does PMBOK have anything to offer the Agile community of practice?
A great way to begin asking this question is to review The Software Project Manager’s Bridge to Agility. The authors compare the traditional (PMBOK) approach and the Agile approach to software project management. It becomes quite clear that for most of the traditional project management functions (e.g., scheduling, estimating, task management, etc.) there is a corresponding Agile approach. However, when it comes to how, who, when and to what degree these functions are performed there are big differences.
It’s also true that project management functions generally cannot be mixed and matched between the Agile and traditional approach.
For example, let’s consider the traditional approach to scheduling. You schedule all the activities that need to be completed for the entire project, usually at the task level. To schedule the tasks you need to know their duration, so task level estimation is necessary to complete the scheduling. You also need to know what work needs to be performed, so scope must be detailed enough to define work at the task level and scope must be fixed up front. Scheduling (and consequently, estimation and scope) all need to be completed before software development begins. This is because the schedule is the backbone of the project plan and as such will form the governance framework for the subsequent effort. The project plan is the law that governs the project, and the project manager enforces the law. Changing scope is equivalent to changing the law. That’s why change request approval may require the functional equivalent of an act of congress.
In the above example, we can see that the various project management functions are not easy to decouple. So if you choose the Agile way then you generally need to go whole hog.
If you went whole hog Agile and then adopted either PMI Agile practices or Scrum, would there be anything left in the PMBOK toolbox for you to consider?
Let’s consider one traditional practice. The weekly status report is an essential element of the traditional approach to project communications. However, it is often abandoned when a team goes agile. The reasons why include two key arguments:
- Emailed weekly status reports are not read and the metrics they (traditionally) report on don’t effectively measure status anyway.
- Much more useful for understanding the true status of the project is the information available at any time by simply reviewing the charts and metrics that are prominently displayed by the team or by participating in the frequent sprint reviews, daily stand ups, and the like.
Conclusion: Rather than waste energy on useless email pushed out to stakeholders, simply invite stakeholders to inspect the team and work and see real progress measured in real time.
What might be wrong with this argument?
First of all, if the content of the status report consisted of Agile metrics rather than bogus metrics (e.g., percent complete on design), maybe there would now be a reason to read the email. But more importantly when we stopped pushing status out from the team, we shut down a communication channel and we replaced it with a new channel using a different mode (self-serve at the team site). What if the people we were communicating with don’t have the ability to visit the team? Who will make sure that these proceedings are available remotely? What if what the team is talking about is not what the stakeholder needs to know, when they need to know it? Who will take responsibility for these tasks?
If this is a new scrum team where the ScrumMaster was drawn from the development ranks and the business analyst designated as product owner is trying to master a new role and keep up with the team, the likely answer is nobody.
An experienced project manager would never make this mistake. She would have known that, although 20 of the 30 recipients will never read the status, the politics of the organization demand that they receive it. She would have known that certain metrics, as irrelevant as they are for noting project progress, are still a requirement to fulfill the corporate governance policy of this publically traded company. She would have known that three of the 30 recipients were vitally concerned with progress but would never be in a position to visit the team and needed information not in the status report, so regular conference calls would be needed. She would know exactly what the status report did and did not do. No one told her these things. She took the initiative to find them out because her experience told her that for this kind of project there would likely be these kinds of communication requirements. She would never have confused the artifact of the communication with the value of what needed to be communicated.
Unfortunately, there was no experienced project manager assigned to this project. The candidates who might have assumed these tasks, the Scrummaster and the product owner, did not because they were unaware there was any need, in part because they had no project management experience. If asked, "Don’t you need a project manager?", they might have answered,
“No, all the important work is done by the product owner, me or the team. All that’s left for a project manager to do is send the weekly status report, and we all know how much that is worth, right?”
Actually, no. Only the experienced project manager knows the real and limited value of the status report and other project management communication techniques. Similar arguments could be made about project risk management.
Let’s look at my manufactured controversy from another perspective. What we have is a conflict between two Agile principles. On the one hand we wish to avoid mechanically doing non-added-value administrative tasks because they are wasteful. On the other hand, we do everything in our power to strengthen the working relationship with our customer stakeholders. A judgment needs to be made that balances these two countervailing forces. And to make a good judgment call you need the practical knowledge, which we can always hope is a side effect of experience. With this in mind, let’s return to our PMBOK toolbox.
There are tools inside the PMBOK toolbox that can complement Agile practices, but the knowledge to use them is inside the heads of experienced project managers.
The PMI Agile certification unites the emergent Agile community with the traditional project management community of practice. And as they collaborate, they will share their experiences and learn from each other.