Overcoming Resistance to Extreme Programming

src: Overcoming Resistance to Extreme Programming - Benji's Blog - 2025-01-01

Abstract

Teams practising XP can be highly effective and have great joy in their work. Paradoxically this can’t be imposed, its effectiveness is counterintuitive, and faces resistance from all quarters. You can help by sharing what works, inviting folks to try, and coaching. 

Resistance is not futile. If you try to force change like the Borg, your efforts to help teams will likely be foiled. Even worse, if you succeed at imposing your desired change, you’ll destroy the very potential of those you’re trying to help. 

In my experience teams following Extreme Programming (XP) values and practices have had some of the most joy in their work: fulfilment from meaningful results, continually discovering better ways of working, and having fun while doing so. As a manager, I wish everyone could experience joy in their work. 

I’ve had the privilege to work in, build, and support many teams; some have used XP from the get go, some have re-discovered XP from first principles, and some have been wholly opposed to XP practices. 

XP Teams are not only fun, they take control of how they work, and discover better ways of working. 

Who wouldn’t want that? Where does resistance come from? Don’t get me wrong; XP practices are not for everyone, and aren’t relevant in all contexts. However, it saddens me when people who would otherwise benefit from XP are implicitly or accidentally deterred.

Developers discount XP based on misconceptions. Managers say they support collaborative working while simultaneously reinforcing incentives that demonstrate the opposite. Let’s explore sources of resistance to XP from developers, management, systems, and tools, along with how to help…if appropriate.

Paradox of Giving Control

One cannot coerce teams to take control. Control must be taken. XP Teams take control of and own their ways of working. Management imposed XP is not XP. 

Supportive managers have significant power to influence ways of working, but can only invite and encourage ways of working; coercion cannot create teams that take control.

Developers’ resistance to XP

Curiously, given XP’s origins, much resistance to XP ways of working comes from developers. Perhaps even more so than management. 

It’s not what we’re used to

XP practices are incredible, in the full sense of the word. Not only are they highly effective but it is often difficult to believe they will work well for you, until you’ve had the chance to try them.

Most developers are familiar with the open source development workflows that have gained popularity thanks to GitHub—Long lived branches, pull requests, individual autonomy and collaboration amongst large groups of people across many time zones. This way of working is effective for large open source projects but it’s not as effective as small teams can be at working together towards a common goal. 

Furthermore, many XP practices are both counterintuitive and require a lot of skill. TDD is hard if you’ve not had the privilege to work in a team skilled at it. Many folks say they practice TDD, comparatively few do or can. Ditto Pairing. Ditto CI. People think TDD is about writing “the tests” first, think pairing is about discussing code from time to time, and think CI is about test/build automation. Actually integrating your changes every hour, driving implementation from a single failing test assertion for the next micro-unit of behaviour, and working collaboratively with another person throughout the work are both hard and unfamiliar. 

Pairing conflicts with the popular understanding of “flow”, and stereotypes of introverted developer needs. Pairing requires skill at collaborating in real time. It feels less efficient because you’re shaping the design collaboratively as you go rather than hammering out your personal vision. It takes experience of good pairing to see how flow is improved by continuity, resistance to distractions, and focus on different levels of abstraction throughout. It takes experience of good pairing to see how it saves on re-work on review. It takes experience of good pairing to be convinced it’s fun, even for self-identifying introverts. 

CI conflicts with the popular experience with pull request workflows. It takes skill to break a change down so that you can make an integrable small step in less than an hour. It takes humility and compassion for yourself and your team to accept the overhead of breaking work down into such small steps. It takes experience to see how working in small steps with some overhead of crafting each step will save time in the long run with less rework or breakages. 

TDD is hard, perhaps the hardest of the XP practices to learn, it requires both expertise and also humility. The humility to accept that the design may end up better through working in smaller steps with continuous feedback, than it would through shaping it out first.

These factors often lead to bad experiences where people see more examples of misunderstandings  than good practices. This leads to misnomers like  “TDD couples the tests to the implementation”, “pairing is for extroverts”, and “you must have CI on a branch“

Developers’ resistance to their own understanding and experience of XP practices are not then wrong or surprising. They likely will be more effective with the ways of working they understand and have become skilled in, even if they’re at a local maximum, even if their team could be more effective.

Individual Autonomy is Glorified

Popular developer culture glorifies individual autonomy and preferences above all else. What helps an individual focus, get into flow, get most done, avoid distractions. Maximise flow, minimise meetings. 

Embracing XP values requires embracing what’s best for the team and the team’s outcomes; at the expense of individual freedom and productivity. 

This wrankles.

Pairing requires preceding at the speed of conversation, and often accepting a more emotionally draining way of working. Pairing requires agreeing on a common tech setup often involving tradeoffs from keyboards to editor of choice.

CI requires effort to keep your changes integrated with everyone else’s rather than blasting off alone.

In short it needs humility and a commitment to the needs of the team. 

The needs of the many outweigh the needs of the few. 

Management incentives that resist XP

Of course resistance to different ways of working doesn’t just come from developers, managers have even more influence. Even managers who think and say they support collaborative working may be oblivious to the ways they signal and support systems that demonstrate the opposite.

Rewarding and Managing Individuals

Do you have OKRs for individuals? Are you performance managing individuals’ outcomes? Do you build promotion packets for individuals based on their direct contributions to the company results?

You are incentivising individuals to avoid collaborating and maximise their individual visible contributions. 

There’s a paradox for managers that managing individuals and optimising individual performance undermines team impact. You lose out on the impact multiplier that teams can have.

Helping teams means switching from holding people accountable for output, to holding them accountable for behaviours. This is often uncomfortable; it’s easier to point at a number that’s not good enough, than have a conversation about behaviour that isn’t meeting your needs or the team’s needs. 

Short termism

Management incentives often conspire to maximise short term results. How much can we get done this quarter, this week, today. It requires effort to support sustainability and protect teams from self-imposed deadlines and urgency stealing their discretion to work collaboratively.

Lack of time discretion 

Can your teams choose what they work on day to day or is their time managed and tracked to project plans and budgets by armies of bureaucrats? Without space to adapt, nobody will.

Lack of Control

Does everyone have to use Jira? There’s your problem ;)

Is a team allowed to not plan every week? Can they choose to not have a standup? Can they work differently?

“But how will we track without standardisation?” You won’t. “How will we manage without metrics?” you have to have real meaningful conversations, not just watch numbers on dashboards that are comforting lies.

Teams need control over their ways of working to be able to uncover better ways of working.

Tools reinforce resistance to XP

The tools we use, and the language and metaphors they employ have a surprisingly big effect on our ways of working.

This impact was starkly visible when a team switched from having daily “standup” conversations from around a Jira board, to a freeform custom layout for their workflow on a Miro board. There was an immediate improvement to the quality of conversation around who needed to work with whom on what, towards which outcomes.

Not to pick on Jira (but it’s such a good example of a tool antithetical to agility) Jira encourages each “issue” (everything is a problem) to be “assigned” (not self organised) to an individual (not a group). The default board view focuses on the work and not the team.

Similarly Github’s UX nudges towards work in isolation, and asynchronous blocking review flows. Building porcelain scripts around the tooling that represent your team’s workflow rather than falling into line with the assumed workflows of the tools designers can change the direction of travel.

While completely compatible with collaborative team-working when used in the right ways, commonplace tools are source of friction to departing from the most common workflows. Friction nudges teams who are starting to explore working together back towards isolation. 

How to help overcome resistance

As a manager, or member of the team with sufficient influence, how can you help teams discover the joy of ways of working that you’ve enjoyed?

Should you?

It’s fundamental that a team is in control and owns its ways of working. That has to include ways of working that you think are worse. 

Help must be offered as a gift, not as a mandate to work in a particular way.

So how to help?

Don’t force it

Explicitly give control to the team and invite them to try new things.

Hiring

If you’re a manager you likely have significant influence over hiring. Hiring people with experiences you think will be beneficial into the team, can have an enormous influence on the team culture and effectiveness. 

However, transplants can be rejected. Beware risks of trying to transplant people you’ve seen succeed elsewhere in different team cultures. What worked elsewhere may not work here. People who were highly effective in other team systems may be ineffective here. Bringing someone who wants to work in a different way into a team may help transform things for the better… or make the existing team and the new joiner unhappy. 

Furthermore, teams that really take control of their work, also take control of hiring. Overruling team hiring decisions will undermine their trust that you genuinely want them to take control.

Share experiences  

What have you seen work? How did it play out? What pitfalls were there? Your team may not have experienced these things, at least share what you’ve seen with them.

Practise together

If you have the time, skills, and trust, getting hands on working with the team can help. Giving folks the experience of working with beneficial practices is a powerful tool. 

The counterintuitive/countercultural nature of some of the practices mean that the best way to understand how they help, is to see it in practice through working with someone experienced.

Coaching

You can help through individual coaching; asking the right questions and inviting people to discover better ways and why, themselves. Beware advising people to do things the way that worked for you, instead be curious, and ask how you can help rather than imposing your help.

Accountability 

A team deciding to try a new practice may never really give it a proper go. Pairing may be squeezed out by some of the management incentives above that they aren’t even consciously aware of. Holding folks accountable to behaviours they’ve agreed to try/change shows that you care and support them. 

Inquiring about dropped working agreements can help signal that you see them as more important than whatever contrary signals you may be sending, unbeknownst to you, through the wider organisational incentives. 

If you’re not a manager you can explicitly ask your manager to help hold yourself, the team and team members accountable to working agreements.

Explicitly Make Time available

Time pressure gets in the way of trying new things. Like the proverbial “too busy to try the wheels“. Try making time explicitly available through simple habits like “On Fridays we mob program”, “We start each morning reviewing code together”, or “We leave a week between planning cycles to try new things”

In summary

Teams practising XP can be highly effective and have great joy in their work. Paradoxically this can’t be imposed, its effectiveness is counterintuitive, and faces resistance from all quarters. You can help by sharing what works, inviting folks to try, and coaching. 

What else have you found that helps? 

Good luck helping!