The Inclusive Team Tests are a collection of tests which can be used to roughly determine how inclusive a team is of a particular group. The level of inclusiveness (or disadvantagement) that a particular group might experience within a certain working environment can be expressed as a score on the test. The concept for these tests was heavily influenced by The Joel Test.
Have you heard of The Joel Test? Go ahead and follow that link and read the article if you haven't. This can wait 'til you get back.
In case you haven't read it or don't go read it right now, here is the intro (from the linked article by Joel Spolsky):
I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school.
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. You don't have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.
A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
Of course, these are not the only factors that determine success or failure: in particular, if you have a great software team working on a product that nobody wants, well, people aren't going to want it. And it's possible to imagine a team of "gunslingers" that doesn't do any of this stuff that still manages to produce incredible software that changes the world. But, all else being equal, if you get these 12 things right, you'll have a disciplined team that can consistently deliver.
This is a wonderful concept and the test has become a widely accepted "grassroots" metric for the software industry. A number of companies now advertise their "Joel Test Score" during recruitment and many of the topics that the test covers are discussed on a regular basis (whereas previously they were often ignored).
The Joel Test has definitely raised the bar of expectations. Although it's an imperfect and sloppy test, it has been effective in improving the overall quality of companies by stating in simple terms the expectations and values that make a great software team.
The world needs The Joel Test for other topics as well: specifically, measuring inclusiveness and disadvantagement.
- Inclusiveness means that no group is alienated by the practices and culture of a team.
- Disadvantagement means measuring whether or not a team provides a level playing field vs creating an environment that advantages certain groups of people over other people.
A concrete use case is always a good starting point. To make it easy, let's pick a group and environment and roll with that. One of the more glaring issues that any developer will be familiar with: women in technology.
Women are a disadvantaged group in the technology industry. Women don't get hired as often, they don't get equivalent salaries, they get subtly (and sometimes not so subtly) discriminated against and mistreated once they have a job. Sometimes there is no obvious mistreatment but they don't feel welcomed or appreciated compared to others on the team and nebulous matters of "fit" become very problematic.
There are a lot of things to talk about here and there are a million reasons why, but for now we don't need to discuss those reasons or describe the problem in too much detail. We just want to do a quick and dirty measurement to see if a technology company does not disadvantage women.
Here's an example test: The Ada Test after Ada Lovelace.
The goal is for no group to be disadvantaged, so to address that, we start by applying some basic metrics using the test score metaphor.
- If your company scores 11/11 or even as low as 9/11 on this test, high fives. That's awesome and rare (though it should be the standard).
- If your company scored 8/11 or less on the above test then there are serious problems which should be a red flag to a woman who is considering working for your company.
Hopefully, folks will come to job interviews armed with this test. Hopefully, employers will self-test and will either reflect on how to improve their environment, or will proudly display their high Ada Test scores in their job advertisements.
The goal of this project is to create a generalized test which can be applied to any situation and from that base, create numerous more specific tests which focus on certain groups and environments, each with their own unique names.
In the Ada test, one could easily replace "woman" and "women" with any potentially disadvantaged group, like say "homosexuals", "Muslims", "little people" or "people of color". We could even replace it with general terms like "the concerned group member". By stating a test in general terms it would allow that test to apply to a lot of situations rather than just focusing on a particular demographic in a particular kind of environment.
This project can collect and maintain these tests and ensure one is available for any scenario.