Ending the Methodology Wars

I was in a meeting the other day when I encountered a bizarre exchange between a project manager and her project sponsor. I followed up after the meeting with both of them individually to try and figure out what was going on behind the scenes—clearly, such strange reactions indicated some political intrigue was brewing in the back rooms and hallways of the organization.

What came out of my investigation was a better insight into how poorly we communicate when discussing change initiatives—and most projects could easily be classified as “change initiatives.” The project manager and the sponsor thought they were miles apart in their perspectives and were arguing over their different approaches. The project manager, after assessing the unique characteristics of the project, strongly believed that agile management methods were best for the optimizing the delivery of that project. The sponsor was concerned about governance, control, and risk; as a result, he went with the only approach that he knew that provided the maximum control: a serial/sequential (a.k.a. “waterfall”) approach to project delivery.

Ah, it was the old “waterfall versus agile” argument—many have seen this before in their own organizations. What was interesting here, though, was that what the two parties were saying about the other’s approach shone a clear light on the problem underlying the whole argument. The project manager and the sponsor were not arguing over methodologies; rather, they were poorly communicating their concerns (fears) about the project and their own hidden desires for what they want to get out of the initiative.

The sponsor had deep concerns about the ability of the IT team to deliver. In past, they had surprised him on numerous projects with requests for additional time and money due to a range of reasons that he felt they should have been able to predict better: unstable technologies being used, inadequately-skilled resources assigned to the project, the impact of assigning people to multiple simultaneous projects and the conflict in priorities that this creates for them on a daily basis, significant design defects uncovered late in the testing cycle at the end of the project, and many other examples. In short, the sponsor had no trust in the IT team. As a result, he wanted to fall back on what he knows best: a strong command and control approach to this mission-critical project. So, he was trying to impose a sequential phasing approach, with management stage gates for control points, and requests for detailed plans up front that incorporated risk mitigation activities and accounted for all of these possible problems.

The project manager, understanding the critical nature of the project, wanted to ensure a quality delivery in the most efficient way possible. She used agile approaches for the benefits of continuous prototyping and testing flush out any serious defects early on in the project, with lots of time left to correct them and still make the delivery date. She also liked the ability of the agile approach to minimize overall project risk on such a complex initiative—in past, when her IT team had tried to do an up-front design for a similarly-complex system, the team got mired in trying to come up with a “complete” design when the detailed requirements were still emerging. She saw agile methods as a way of dealing with the change and the complexity of the solution.

What really struck me as interesting was that both parties wanted the exact same things: a reduction of risk, a high-quality output, and the completion of the project in a relatively short period of time. What was underlying the argument was a misunderstanding of each others’ terminology and unstated desires. Let me address these separately.

If the two parties trusted each other enough to share what they really hoped to achieve with the project—on a personal level—then they would have more quickly come to agreement on the approach. The sponsor had made commitments to his own boss about the quality of the product and about the final delivery date—which was tied to his own performance review—so he was fearful about schedule delays, which was why he was insisting on so much up front planning and management involvement; he wanted a level of comfort that his commitments could be met. The project manager was using agile methods that would likely deliver a higher quality output, and agile methods, by building in short iterations and always working only on the next most important items, would ensure that if problems arose and something had to give in order to make the key deadlines committed by the sponsor, then the scope items to drop from the list would be naturally the lowest priority items that the sponsor could likely live without (especially if his performance bonus was on the line).

The terminology differences would perhaps be easier to resolve. The sponsor was concerned over the use of extreme programming (XP) techniques on such a critical project. In his mind, he didn’t want anything “extreme;” rather, he wanted stable, predictable, and guaranteed. As soon as the word “extreme” gets mentioned, his back goes up and his fear increases. Instead of continuing to push the use of XP, the project manager should have discussed the practices in XP that would minimize risk, improve quality, and improve communications and visibility thereby addressing the concerns of the sponsor. We often get caught up in the extra meanings that we layer on to words end up dealing with the emotional response which clouds our rational thinking. We need to be aware of this issue, and take care in choosing our words. My advice to the project manager would have been to suggest that she focus on the business benefits of the various practices, describing them in non-technical business-stakeholder-friendly terms. In that way, she would have been talking in her sponsor’s own language, describing how she is addressing his own personal concerns, and showing how his business case needs were being addressed.

So, these methodology wars that we come across in our organizations can be avoided. We just need to be more careful with our communications. In the end, both parties usually are trying to achieve the same thing.

Kevin Aguanno is a certified Executive Project Manager who specializes in recovering troubled application development and systems integration projects, often using agile methods. He has published books, articles, audiobooks and DVDs on the topic of agile management and how to adopt agile into an organization. For more details, visit www.AgilePM.com where you can sign up for his free AgilePM Newsletter.