Project Managers and Methodologists - The Zealots

The joke goes, “Question: What’s the difference between a terrorist and a methodologist? Answer: You can negotiate with a terrorist!” Beware the methodologist and remember as far as they are concerned it never the methods fault, it’s your fault for using it incorrectly. Now before you get the wrong idea I’m not opposed to project and process methods. I sincerely believe they can be very beneficial. What I’m warning against is the inflexible application of methods in inappropriate situations.

There are two main groups that you need to deal with. The first one are the true believers - the Jihadists. 

These are the true believers in a method and they demand a pure implementation of its tenets no matter what it means in practical terms. So we get things like: Agile is the best and everyone must be co-located – even if half our team is in India, ISO9000 QA is essential so we must have a procedure for everything – including booking meeting rooms and ordering tea and biscuits for meetings, DOD specifications are paramount so a five man project lasting eight weeks has to follow its every stricture, the list goes on.

Zealots of any kind are dangerous and particularly so on projects. It’s their inability to compromise and address the practical issues in a flexible manner that is dangerous. It’s rare that you go for guidance on a method and come back with a quicker way of doing the job, one with less paper work to complete.

Plus methods, like religions have their various sects, the latest software method is called Agile. Within Agile you have: Scrum, Extreme Programming – XP, Unified Process, EVO. You have variations within sects, so you have Crystal Clear, Crystal Orange, Crystal Red and so on.

Now I do believe that Agile methods in certain circumstances are a real benefit. Just as I believe that Theory of Constraints principles are of value and good old waterfall processes have their place. They are all tools that have a place in project management. It’s all about using the right process for the task in hand

The problems arise when the methodologists insist one size fits all, and it’s their size, or you have conflicting methodologies in play at the same time. Currently in software development you have Waterfall and Agile slugging it out. We are experiencing as Kuhn would say, a “paradigm shift” from one way of doing things to another. And, also to use Kuhn again, the practitioners are talking past each other. Communication is poor to non-existent between the groups.

How do you manage this situation where you might have one part of you project being run by one set of methods and another part by another set and the output from one affects the other? If they are complete separate teams with no interaction then problem solved. They both stay on their relative islands and ignore each other.

Now I’m assuming that you’re an agnostic in this situation, basically you don’t care which method they use as long as it meets your schedule. Even if you do have strong views then the following advice will still be useful.

Firstly don’t try and force one group to adopt the other group’s methods. That is a sure recipe for chaos. If they have a proven way of working that delivers results let them use it. Don’t turn your project into a test bed for method re-education unless it’s unavoidable. Don’t try and get the adherents of the ‘new’ method to revert back to the old method. Team morale will plummet: people may leave the company.

You have to manage the interfaces between the teams and ensure that they communicate in a way that the other team can understand. Typically waterfall teams work on clearly defined product specifications, they expect signed off technical requirements documents as a given. Agile team’s work of a product function backlog and change specifications as the need arises. So there are genuine communication issues. Typically a Waterfall team supplying Agile team has less conceptual problems that an Agile team supplying a Waterfall team.  But they still have problems and you have to get the team leads together to determine how they will work together before commencing the work. You may have to knock heads together for the benefit of your project. You will be involved in ‘shuttle diplomacy’ between the teams and at some stage you may have to escalate the teams to their management if they refuse to play nice with each other. As I’ve mentioned before it’s all about managing the interfaces and the politics that are associated with them.