Process Police
Readers of my book and articles know how much I value a strong project manager. I’ve written earlier about the positive impact to velocity a great project manager can have (see http://www.svpg.com/ebay_secret_weapon/ and http://www.svpg.com/product-management-vs-project-management/. And one of the reasons I advocate for Scrum is that as a process it values this role of project manager as “impediment remover” (known as the Scrum Master role).
However, occasionally I run into teams where they have a very different type of project manager. You can generally spot the situation because software development moves very slowly, and the team tends to view the project manager (or Scrum Master) as an obstacle rather than an obstacle remover.
We call this type of project management “process police” because that’s how they perceive their job; they view themselves as the enforcers of the official process. Following the process becomes an end in itself.
But of course process is there to help us and not to hinder. The best project managers know when the process itself is the impediment and they adjust accordingly.
One of my friends, Jeff Patton of Agile Product Design (see www.agileproductdesign.com) and one of my favorite Scrum Trainers because of his focus on product teams, has also observed this problem. “A sure fire way to fail at a process is to work too hard to follow it. Even worse is forcing people to follow it.“
Jeff goes on to say “Judging a process based on how well people comply is like judging a product based on whether all the features were delivered on time - it misses the point. I also see Scrum Masters being policeman pushing by-the-book agile (at least by the books they've read) - which haven’t been adapted for product organizations.”
Another common problem that I see is when the project manager tries to fit all types of software into the same “one-size-fits-all” process. But in product software teams, we generally work on all types of software efforts, from very small fixes, performance improvements, and minor features, up to large projects and company-wide initiatives. It makes no sense to treat these all the same. The level of investment is totally different, the risks are totally different, and the techniques we use to ensure success are different.
It is not that project managers don’t care about process as they do. But the project manager should facilitate the process, making sure people understand the roles and how they should collaborate to come up with strong products.
“I hold Scrum Masters responsible for process health - which is essentially the quality of collaboration across the whole team, the removal of impediments that slow down the team, and the coaching and improvement of everyone on the team,” says Jeff. “Where I see the Scrum Master go horribly wrong is when they take the ‘protect the team’ posture and try to keep the product owner away from the team during the sprint. We need effective communication between product owner and team - not no communication. I've seen bad Scrum Masters damage the relationship between product owner and team - building distrust between them.”
If the project manager or Scrum Master on your team is more concerned with process enforcement than process results, then pass along this article and maybe he’ll take a fresh look at his role and try to focus on the result of the process more than the adherence to the process.