Stop me if you’ve heard this one. The next big project is in trouble. A high performance Project Manager is brought in to bring it to fruition. They come in guns blazing. Change this process. Remove that documentation. Do these tasks. They know what needs to be done and by golly they are making sure it gets done, and now! If you aren’t part of their solution you are part of the problem. They will dictate what gets done, when it gets done, and how it gets done. The project finishes. Over budget and late, but it was failing when the new PM came on-board. It matches what was originally asked for to a T. It is considered another big success for the PM. Within a week the customer has a list of what doesn’t work and needs to be changed.
What about this one. The next big project is in trouble. An Agile Coach is brought in to bring it to fruition. They first observe what is happening. They talk with the team about delivering minimum viable functionality as quickly as possible. They talk with the Product Owner about what really comprises minimum viable functionality. They further work with both parties to break it down to least amount of functionality that can show what is being made. They bring that back to the team. They ask the team to meet a goal of the first piece of it in a short time-frame. They let the team decide what tasks are required to meet that goal. They show what is being made and solicit feedback. They connect with management about the process and how to allow it more freedom to succeed. The project finishes. On time and budget, but with a very different product than originally asked for. It is considered a big success for the team. Within a week the customer has a list of extra functionality they would like.
Obviously these are extreme examples. They are also obviously skewed to the path I have chosen. Thing is, I think most Project Managers can see the truths in the classic view just as readily as good Agile Coaches can see the flaws in the new one.
Command and control is important to classic project management views. Plan the work and work the plan right? PMBOK has almost 40 pages just dedicated to the managing Project Scope for example. The classic Project Manager is expected to break down and control tasks which are completed to provide deliverable’s on a project. This classic PM understandably guards the plan carefully and is resistant to changing it. However, the PM doesn’t create this plan in a vacuüm.
Experts on the team assist the Project Manager in making the plan. Team members and stakeholders are involved in the change management process. Without a solid project team the PM will fail in delivering the project. We all know this. The classic PM likely doesn’t know how long it takes a person to do each task required for the project, if they even know what each task is based on the requirements. They know how to organize all the information, maintain it, and present it. They use the gathered information to make informed decisions. Presentation of info and informed decision-making is what makes the PM seem like such a hero on the project, not their personal ability to complete tasks.
Individual empowerment and value delivery are core to what an Agile Coach does. There is a plan. However, for the coach the end goal of the plan is more important than the steps taken to get there. The Agile Manifesto pushes Individuals and Interactions to the forefront with Working Software. It does not get rid of a processes and plans but puts them as secondary. The coach guards the team over the plan.
The Agile Coach has a team just as the Project Manager does. The coach is more pro-active in pushing the team to make decisions based on the goal though. This can be problematic in a weak team. A strong project team will take this freedom and push towards the goal in ways the coach may not have envisioned. The coach is going to push the team to deliver value towards the goal as often as possible. On top of that they will facilitate updating the goal based on delivered value along the way. While the danger of a moving target for the team is real, short cycles of value delivery and feedback will minimize the negative effects.
In the real world neither of our examples above really happens. Classic Project Managers’s collaborate a lot more than we Agilists like to admit. Agile Coaches care more for the goal of the plan than PM’s generally realize. In the real world PM’s and coaches both work for the same goal. They even get there with more overlapping methods than either one would like to admit. The real fallacy is in the title, the word “versus.” When PM’s and coaches work together the best of both worlds can be realized. When coaches accept that sometimes a little command and control is necessary they will help the team improve faster. When PM’s allow that value might look different along the way than originally envisioned they will produce a better product in the end.
What kinds of common ground do you see Project Managers and Agile Coaches missing? What differences should they embrace in the spirit of the whole being more than the sum of its parts?