This benefits society when developers defy those with greater power. It harms society when developers bully people with less power.

At the ThoughtWorks sponsored Agile East, Martin Fowler spoke to his post, SmutOnRails.

Part of the community was offended by a presentation at the GoGaRuCo (Golden Gate Ruby Conference). Others fought back saying that no offense was meant, the presenter apologized, and that the tone was in the spirit of the Rails community.

(T)he view of the rails leadership seems to be this: that the objections to the presentation are yet another attempt to foist empty corporate values on the thriving Rails ecosystem… (more)

This debate is not unique to the Rails community. It reminds me of concerns my friend, Luke Melia, raised over jokes and behavior at the first Austin Alt.NET. Martin Fowler links off to a similar controversy in the Flash community.

It is also not unique to developer communities but developers in particular need to be concerned about the outcome.

Women, African Americans and Hispanics are under-represented in IT and even more so in software development. In 2001-2002 74.4% of software developers were men. 78% of those men were white.

In 1986 the percentage of women in CS programs peaked at 37%. The percentage of women in computer science programs has gone down since then.

In 2001-2, only 28 percent of all undergraduate degrees in computer science went to women. By 2004-5, the number had declined to only 22 percent. — What Has Driven Women Out of Computer Science?, NY Times

There were 15,000 women in CS progreams in 1986. Riding natural cycles this number was not matched again until 2003. This latter number contains a higher percentage of non-resident aliens who will not necessarily contribute to the US workforce.

This despite higher percentages and numbers of women acquiring college educations than men. In 2007, 33% of women 25-29 held a four year degree or higher versus 26% of men. 55% of graduates with four year degrees or higher aged 25-29 were women.

Women are even receiving the majority of degrees in science and technology. They have shown steady progress in biology, chemistry, physics, mathematics and engineering.

Metrics can be misinterpreted but these quantitative measures support a stunningly obvious anecdotal observation. US software developers are a white male enclave.

This is a power imbalance and we developers are part of the problem.

Isolation is a key factor for a higher attrition rate among women and minorities, said Teresa Dahlberg, director of the Diversity in Information Technology Institute at UNC Charlotte. People tend to associate with “like communities,” where people have similar backgrounds and interests, she explained. — Computer science lacks women, minorities, SD Times

So when we behave in a way that marginalizes and intimidates talented women and minorities, we abuse power. We become bullies. We are oppressors.

“There is a good amount of research that shows that women are judged more harshly than men, for hiring, evaluations and promotions,” she added. “Virginia Valian [author of "Why So Slow? The Advancement of Women"] shows this for women in science, technology, engineering and math faculty jobs.” Virginia Valian is a professor at Hunter College. — SD Times

Part of the problem may be a perception that software development doesn’t contribute enough to society. To the degree this perception is true it is damning. To the degree it is just a perception we have work to do as advocates.

Our actions need to be judged not by our intentions but by the outcome.

Requisite variety within our teams remains an essential enabling condition for sustained innovation.

Access to technology is growing across all tiers of class, race and gender both in the US and overseas. Diverse teams can better address our market and build software better adapted to our end users.

A more diverse workforce provides the kind of social change that will help us create a more humane workplace for developers.

Finally, anything that limits the number of able US software developers hurts our ability to compete.

When developer communities marginalize women and minorities, we conspire to isolate ourselves from the larger society. We defeat our own attempts to change the power structures around us and improve our lot and our output.

Anything else is waste and waste must be rooted out.

Still it is hard.

Luke Melia wrote about how he performed as functional manager and dedicated 75% of his time pairing.

There are two tremendous challenges with this.

The first is limiting distractions in order to remain a reliable contributor.

Luke has tremendous reserves of focus and enthusiasm. As his manager, I did everything I could with our scrum master, Salim Divakaran, to support him, remove distractions and share workload.

The second challenge is being both the boss and a peer.

Luke recruited most of the team, he held weekly one on ones with each person, he insisted on unvarnished feedback, and is worthy of respect as both a peer and a manager.

So, here is the pattern: An experienced coach with people skills and authority over development practices pairing in with the developers. An experienced scrum master. Functional management residing in one or the other or divided up in some sensible and easily described way among the two of them.

This enables direct participation in the work, management attention to the team, and strategic contribution to the rest of the company.

A metaphor for the Scrum Master is a vigilant sheepdog protecting their flock.

At the Fall Scrum Gathering, I met practitioners facing different challenges in their agile practice.

Some faced profound impediments that their organizations were unable or unwilling to address. The effect on the project and team was dire and the Scrum Master had exhausted all avenues to raise alarm.

It’s human nature, unfortunately, to associate an unpleasant message with the messenger. A vocal Scrum Master can be seen as the problem.

In those fraught circumstances a Scrum Master has to balance the interests of the team, the company and themselves. Can the project deliver in spite of the obstacles? Should the Scrum Master accept the dysfunction or not? At what cost?

As Ken Schwaber says in Agile Project Management with Scrum, “A dead sheepdog is a useless sheepdog.” Still, a useless sheepdog is also a useless sheepdog.

As JP Boodhoo says, “develop with passion.” As my friend Luke Melia says, “live with passion.”

As a developer joining Oxygen NY in 2001, I entered a code and fix culture under a facade of waterfall planning. I fought arbitrary dates, bloated specifications, and reality-challenged reporting. I acquired a survivalist’s skill for landing valuable projects and picking co-workers who helped carry them to completion.

As team lead, I made myself project manager. I used a risk-managed, iterative approach based on Steven McConnell’s Software Project Survival Guide and Earned Value Planning. We provided transparency, met dates and exceeding expectations.

Still, I had the awful, lonely feeling it was unsustainable. A tiny team, we were isolated from each other. We needed a collaborative practice. We needed to share knowledge, commit to a common way of working, and lift each other past our individual limitations.

I found the following e-mail thread capturing the moment we adopted Extreme Programming (XP). A bit of everyman’s history with a very small ‘h’…

From: Ken Judy
Sent: Tuesday, January 13, 2004 2:40 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: Agile Methodologies

Here are sites for different agile methodologies. Of the five of them, XP is the most exacting. The others are generally light frameworks for ways of developing or managing projects that support the agile manifesto http://agilemanifesto.org/.

XP: http://www.extremeprogramming.org/
Scrum: http://www.controlchaos.com/
Crystal: http://alistair.cockburn.us/crystal/crystal.html
Adaptive Software Development: http://www.jimhighsmith.com/
Feature Driven Dev: http://www.featuredrivendevelopment.com/

– Ken

From: Luke Melia
Sent: Wednesday, January 14, 2004 5:09 PM
To: Ken Judy; Kristofor Selden
Cc: Keith Frank
Subject: RE: teamwork

Hi Ken,

Kris and I spent some time today reviewing the agile process frameworks you sent around and met this afternoon to discuss our planning. We’re going to follow the XP rules and practices for the most part.

http://www.extremeprogramming.org/rules.html

We will likely invest somewhat more effort in up-front detailed requirements in order to support your work-package tracking efforts. In addition, some practices are irrelevant for a team consisting of a single pair of developers. We’ll ignore those and pay close attention to the practice “Fix XP when it breaks” in order to arrive at a set of practices that is effective for us. I’ve read the criticisms of XP that argue it is “all or nothing” but I feel that this approach will work for us.

We’re going to be pair programming and plan to work together 11am – 1pm and 2:30 – 5pm. This will allow us time at the beginning, middle & end of the day to respond to email, etc.

This is all going to start this Friday. On Friday, we’ll do a code review, go over the task breakdown for the SES project and plan for our first milestone, as you suggested. I’m also going to rearrange my desk to make it work better for two people to sit at.

Luke

From: Ken Judy
Sent: Wednesday, January 14, 2004 5:31 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: RE: teamwork

Sounds good. Our team is so small that a strong agile approach should work well as long as we manage risks. I’ll look into the “Tracker” role in the XP model to see how to adjust my tools to your approach.

– Ken

From: Ken Judy
Sent: Thursday, January 15, 2004 10:33 AM
To: Luke Melia; Kristofor Selden
Subject: RE: teamwork

Hi,

Please go ahead and block out 11:00am-1pm and 2:30-5pm in your calendars as “busy”. I’ll send out an e-mail to IS all so they know what’s up. Feel free to decline any meeting requests at your discretion and let me know of anything in your calendars you need me to cover for you on.

We will need to start the morning “standup” meetings so that we keep focus on the project and one of the things we’ll need to address is how to best use Michele as owner.

– Ken

But besides being a media outlet for women, Oxygen has been building up a reputation in the Agile community, especially in NYC. So, I was very pleased to hear that they were presenting 3 sessions at the NYC Code Camp …

I’ve always wanted to build a learning culture. Before embracing agile principles, we had a hard time fulfilling this aspiration. In retrospect, our definition of the developer role and what constituted success in that role was too narrow. Intensive classes on specific topics don’t suit many learning styles and there was no direct connection between a broader scope of learning and project outcomes.

Scrum and XP require continual improvement. They encourage reflection, engage a broad range of social and intellectual intelligences and tie those abilities to project success. They place you in a larger ecology of peers and mentors.

People striving to make a contribution love learning.