Sunday, July 30, 2006

Diversity on your team

This past week I attended the Agile 2006 conference in Minneapolis. I really enjoyed it and found it to be a great forum to see and discuss agile project practices. I found that the sessions I enjoyed the most where the ones covering or discussing the human side of agile projects. Of those sessions the one that surprised me the most was 'Enhancing Diversity' hosted by Orit Hazzan. Orit is a professor at the Israel Institute of Technology in Haifa and co-author of 'Human Aspects of Software Engineering'.

The session was very informal and mostly based on group discussion of some questions posed by Orit. We started off by splitting into two groups based on diversity, with each group as diverse as possible. We then attempted to identify all the ways in which our group was diverse. This was fascinating - the more time we spent on it the more diversity factors (beyond the obvious) we could come up with.

We then identified all factors of diversity that can help a software project. Things like diverse experience and diverse education were high on the list. Then we identified diversity factors that can hurt a software project. This list was also quite long and included things like political conflict, communication challenges (e.g. non-verbal communication) and cultural norms (e.g. patriarchal societies).

Some of the thoughts that came out of the discussions included the following:

  • Observing metaphors can help to understand other people's perspective. Metaphors are typically used unconsciously and can both hamper and help build understanding across the team. Quite often in IT we apply metaphors that are very culture- or background-specific, leading to a lack of understanding and inclusion for some team members. If we increase our awareness to metaphors we can increase our level of understanding of other individuals on the team. One specific suggestion in the discussion was to restate project problems in non-IT terms (using metaphors). A suggested reference was 'Metaphors We Live' by George Lakoff.
  • Agile project chartering can reduce implicit misunderstandings and increase team cohesion. This practice identifies all of the project parameters and variables that the team has agreed to adhere to during the project. It differs from a traditional (i.e. PMI) project charter in that it covers off specific practices (e.g. Continuous integration) and how the team will apply them. An agile project charter can also be thought of as a team working agreement or constitution. The key is that it binds the team together around a common set of practices that are consistently applied.
  • Agility depends on trust and thrives when people are open-minded. Things like scrum meetings and pair programming can help with this. The role of the agile project leader is to coach for these factors. It's critical to avoid 'us & them' thinking on the team and to encourage responsibility and honesty.

One the quoted references in the conference session was the Carnegie Mellon President's Statement on Diversity:

“I want Carnegie Mellon to be a place that celebrates these diversities rather than merely tolerating them, because being a more diverse institution will make us a better institution. In the classroom, studio, laboratory, office and dormitory, a multitude of experiences, perspectives and beliefs will enrich all that we do. Carnegie Mellon's highest goals will be well-served by raising the consciousness of the entire university community about the inherent benefits of creating a more diverse institution and educational environment.”

Have you thought about diversity on your team? In what ways is your project team diverse? Which of these diversity factors are beneficial and should be encouraged? Which of these factors are problematic and in need of active coaching?

Take the time to think about this on your project - it's easy to build a good homogenous team, but it's far more rewarding to build a great diverse team.