Challenging Agile Resistance

I’ve been lucky enough to have experienced a number of development methodologies in my time, ranging from straight forward Waterfall, to a more iterative RUP style, to a pure-bred XP style. Along the way I’ve been reasonable enough to be open minded and accept other practices. Granted, I don’t think there’s even been a time when the transition was easy. There’s always questions, always pro’s and con’s, and there’s always my opinion regardless of what an organization chooses to dictate.

What’s made my transitioning between the methodologies more difficult is my relative stubbornness – an attitude that was prominent until I hit my XP days. It dissipated (although not completely) then, gratefully loosing the battle with the XP evolutionary mindset.

But, I digress. My point is this; my experiences have led me to believe, without doubt, that XP is is the best methodology I’ve worked with. From a purely selfish point of view, it acts in my best interest by allowing me to focus on what I’d like to do best – learn and develop software. From an organizational point of view, it acts in it’s best interest by delivering higher-quality, maintainable applications, with scope flexibility that is guaranteed to deliver what the business wants - I’m not suggesting other processes don’t do this, but they just don’t do it efficiently as XP.

So, with these beliefs in mind, I find myself working for an organizations that doesn’t practice XP. In fact, I’m fairly certain that before I arrived they had very little idea about the methodology and even it’s practices. Staying true to my beliefs, I’ve discussed a number of solutions to a plethora of project issues with the ‘Powers That Be’, and it’s no coincidence my suggestions have been grounded on XP practices. To date this adventure has taught me that my stubbornness is definitely no unique trait – no surprises there. Importantly, I now appreciate that XP is much easier to teach in a ‘viral’ form – it’s so much easier to understand it’s benefits by actually doing it. The tricky part is getting an organization over the initial hill and convincing them to test drive a practice or two.

I find arguing XP’s theoretical side is easy. For mind, the theory of XP is simple to understand. After all it’s based on long-standing, tried and true, common sense, industry best practices. So the theory isn’t the issue. Getting people to understand how the theory works in practice is. Here’s some highlights of resistance I’ve encountered to date:
- That sounds great, but in the current state of play, we don’t have the time.
- I’m not comfortable with Pair Programming - it doesn’t seem natural, I can’t work with others looking over my shoulder.
- I’ve never had to update my Big Upfront Design after an Implementation. I’ve always been right upfront.
- I believe it’s in a projects best interest to produce reams of documentation. They communicate important messages to a great variety of audiences.
- I don’t believe Practice X works on large projects or in large organizations.
- XP is too radical and promotes shortcuts.
- No thanks, I know this other methodology works for me.

Some of these points are plain old ludicrous and easy countered, others suggest you need to produce some empirical evidence to back up a claim, others still are a strong indication of a closed mindset. In these latter cases I find there’s no alternative but to walk away from the discussion with your objections duly noted – especially when your dealing with decision makers. I find the hardest thing about dealing with a decision maker is when it comes to opinion - theirs counts, yours doesn’t. You need to resort to hard evidence and fact, while, on the other hand, their opinion is good enough reason for them. I can appreciate that they’ve earned that position, but it serves to occasionally obscure them from seeking out and making better decisions. In some cases the decision makers can suffer from Sinatra Paralysis, they just want to do it their way and will naturally resist, finding ways to keep their vision intact. In other cases they can adopt a Whiteboard Approach and rarely practice what they preach, not feeling any pain at ground zero.

Still, regardless of the many setbacks, I’ve gained many positives from the experience of putting forward arguments for adopting XP practices. My positive opinion of it has been re-enforced in the search of counter arguments and justifications. I’ve been able to see, in practice, how it is very capable of solving the many problems more traditional methodologies can and do encounter. I’ve also been able to gain a greater appreciation of the decision makers reasoning and motives.

So, even though most of my suggestions fall on seemingly deaf ears, I pledge to continue making them – I see it as a win-win situation for me and the team regardless. It’s a win for me to put an argument forward and it’s a win for the team to at least considers potential process improvements it offers, regardless of their mindset. There’s always hope that they will one day both hear and listen.

I remember prior to starting my European expedition, The Trigger told me of a proverbial software development jungle on the free market. He believed it was very unlikely I’d uncover a project with a pro-XP mentality. At the time I agreed with him, but I was hopeful it wouldn’t hurt too much. Well Andy, you were right - and it doesn’t hurt that much, well….maybe a little
P.S. Many thanks to the organizers of the recent XP Benelux Day for re-charging my interest. It’s good to know that there’s plenty of other XP practitioners in the region.