May, 2018

Thursday, May 17th, 2018

Is XP Unsuitable for a Diverse Team?

The discussion started on Twitter with this comment from Sarah Mei:

Wondering why all the agile/XP stuff (like pairing, TDD, etc) doesn’t seem to work for a heterogenous team?

It’s because they were developed by a bunch of white dudes. The practices assume the practitioners all have A LOT of built-in privilege.

This got a lot of reaction, as you might expect, with more heat than light evident. Much of that discussion was about what is and isn’t civil behavior on Twitter. I’m not going there because I think that ship sailed a long time ago and it’s not coming back.

I will say that I don’t believe issues of diversity in our software teams are a matter of politics. That is, “flaming liberal” I may be, but I nevertheless don’t expect intelligent conservatives to be opposed to inclusiveness, equal opportunity and respect for everyone in our companies and teams. Of course, I’m sometimes disappointed, but that happens with people who claim to share my political views as well. In the wild, neither liberals nor conservatives have cornered the market on treating people badly.

Back on point… eventually I managed to find a Twitter essay by Sarah Mei that explained her position more fully. Someone has kindly put it together in one place here: I suggest reading it in full.

There’s stuff in there that strikes me as wrong or mis-stated, but other points that strike a chord. In any case, I think it’s a point of view that anyone taking XP seriously has to deal with.

A few minor things first:

1. The folks at Snowbird invented Agile as a term to describe the principles they held in common even though their individual methodologies were quite diverse.

2. Most of the problems Sara Mei describes seem to be around pairing, which is pretty much exclusively associated with XP. In this post, I’m sticking with what I know, which is XP.

So what about pairing? Does the creation of a diverse team make pairing more difficult? I’d have to say “Of course it does!” When we began to move testers out of separate organizations and into XP teams, that made things more difficult. Same goes for database folks, designers, UX experts, etc. It has never been possible to just tell people to pair together and have it work. Somebody has to sit down and show the team members how to do it, just as for any new skill. Failure to show people how to pair is an anti-pattern I saw for years as an outside coach brought into companies that imagined they were doing XP.

That said, diversity in race and gender are a different matter because here we are talking about privilege and disadvantage, not just within the team, but in society as a whole. If the team is 100% in agreement with the need for such diversification, then we “merely” have to teach them how to deal with imbalances of power – real or perceived. Ideally, we would make those imbalances disappear, at least within the team. We would make the team a safe place for its members.

On the other hand, the existing team may not be in 100% agreement. Some may oppose efforts to employ more women or people of color, or to give them equal status. In that case, I don’t think it’s any longer a question of software methodology but of the company’s willingness to enforce standards of behavior.

I didn’t write this post to offer a recipe or a remedy but to call for a discussion of the issue among members of the XP community. Next week at XP 2018 in Porto would be good for me!

Tuesday, May 1st, 2018

What’s With NUnit 2.6.5?

Some folks have expressed surprise at my release of NUnit 2.6.5. Their surprise is no surprise, given that the NUnit framework is now at version 3.10.1!

So why release a 2.6.5 version now?

For an answer, we have to go back to the first release of NUnit 3.0. At that time, we felt that NUnit 3 was going to be so attractive that people would rush to convert. For that reason, NUnit 2.6.4 was to be the last release of the NUnit V2 series. We archived the code and stopped accepting bugs on it.

We weren’t entirely wrong. NUnit 3 is a great improvement, so great that even those who are unable to convert to it wish that they could! And there lies the problem we didn’t consider: there are many, many external factors that can keep people from being able to convert. We knew that this would be a factor but seriously underestimated how many people would be affected.

To make matters worse, as NUnit 3 progresses through new releases, these folks get farther and farther behind, making their eventual conversion that much harder. The list of things you have to change in your code when converting from NUnit V2 to the latest NUnit 3 version just keeps getting bigger. It would be very convenient if folks on V2 could keep up with at least some of the ongoing changes.

Enter the NUnit Legacy Project!

The aim of this project is to support users of older NUnit V2 software in two specific ways:

1. By giving them information about exactly how much of their code may need changing in order to convert to NUnit 3.

2. By providing them with ways to keep their code more closely conformant with NUnit 3, where doing so doesn’t require a complete re-architecting of NUnit V2.

NUnit 2.6.5 is the first software release from the NUnit Legacy Project. It provides enhancements in both of the categories just listed, including a compatibility report that points out the places in your code where changes may be needed in order to upgrade. Additional enhancements in 2.6.5 provide compatible replacements for classes and methods that are no longer supported in NUnit 3, allowing you to immediately reduce the list of compatibility issues you may have to deal with.

Documentation and downloads for NUnit 2.6.5 and coming releases may be found at