How XP Can Improve the Experiences of Female Software Developers

Open Access
Conference paper
Part of the Lecture Notes in Business Information Processing book series (LNBIP, volume 251)

Abstract

This paper describes my experience as a female software developer with 17 years’ industry experience. Originally I worked with a more traditional waterfall approach to software design and development, but in recent years I have worked with XP. I have experienced many difficulties associated with being in a minority, but a lot of those problems have been alleviated since I started working with XP. My belief is that XP creates a more conducive environment for women and other minorities within the industry. I believe that XP can – and should – pave the way to making the tech industry a more welcoming and attractive place for women.

Keywords

Women in technology Women in tech Women in XP Women and agile XP Agile Women Gender Skills shortage Balance Feminism Stereotypes Assumptions Challenging assumptions Recruitment Role models Gender roles Gender equality 

1 Introduction

In every workplace for 17 years, I have found myself in a significant minority as a woman. This is not unusual. In 2014, the average percentage of women working in 11 of the world’s largest tech companies was around 30 %. But the average percentage of women occupying tech roles within those companies was around 16 % [1]. According to the Harvard Business Review in 2008, 41 % of women working in technology ended up leaving the profession - compared to 17 % of men [2].

The experience of being in a minority1 has caused me various problems throughout my career. The most obvious one - which is shared by many women in my situation - is a feeling of insecurity. To put it simply, my chosen profession is one in which it is unusual for women to persevere or succeed. I have had to work hard to maintain belief in my own abilities. I have more than once had to resist or reverse attempts to “promote” me into non-technical roles, which I have found less satisfying and have had less aptitude for.

At one point I left the profession altogether, but luckily I realised my mistake and returned four years later. It was at this point that I discovered XP, and I believe this resulted a significant reduction in the difficulties I face as a woman.

XP is a forward-looking movement which emphasises flexibility, change and progress - so this is the ideal group of people to be addressing the low proportion of women entering IT. As agilists, we value individuals and interactions over processes and tools. The diversity of our teams, and specifically the encouragement of the participation of all members of our populations, is a crucial part of this.

The rest of this paper will be split into the following three sections: My Journey as a Female Software Engineer; Discussing Lessons Learnt: Attracting More Women Through XP and finally Conclusions.

2 My Journey as a Female Software Engineer

In this section I will describe the experiences I have had within my career, the difficulties that I have faced as a woman, and how my journey has become easier and more enjoyable since I started working with XP. I will cover the following topics: Non-XP Workplaces, Imposter Syndrome and its Effects, and finally The Welcoming Environment of XP.

2.1 Non-XP Workplaces

I have 17 years’ experience in the profession, but due to a four-year career break in the middle, it is twenty-one years since I started my first software engineering job. At that point I had just graduated from an MSc in Computation, which was a “conversion” course - designed to transform people from diverse academic backgrounds into computer graduates. My previous degree was a BSc in Mathematics and Philosophy. It was 1995, and Agile and XP were barely heard of.

During the course of the MSc, we were told that the main careers available to us would fall broadly into two categories: Analysis, and Development. The course was a popular course, and split quite evenly between men and women. It was noticeable that the women tended to be drawn towards analysis, with the men being attracted to coding. But personally I was more excited by code than anything else. The object-oriented C++ we were taught was very attractive to my logical, analytical, puzzle-loving brain.

It didn’t surprise me to find that I was the only female developer in my first job. I was used to being in a minority – as a mathematics undergraduate, myself and my fellow female students represented approximately 10 % of the total population. I was also used to an accompanying feeling of inferiority: In this case it seemed to me that my male colleagues knew everything there was to know about computing, whereas I had walked straight into the job after a year’s study.

I suppose it was at this point that a thought took root in my brain, which I have never quite lost: These men know so much more than me. I’m only a girl, I’ll never catch up. This is a common experience for women in our industry, and in fact for anyone operating in an environment as a member of a group which suffers from an adverse stereotype. That is to say, assumptions are often made about women in technology which suggest they will not have the skills they need to succeed. The general term for the way people respond to this is Stereotype Threat, and it is discussed at more length in section three of this paper.

It’s worth stating at this point that I have never seriously believed that men have a superior intellect to women. But the inner voice which tells me I’m inferior is one that sneaks in without my permission. It curls up without me noticing, and can stay there for quite a while before I spot it and shoo it away (I now know that this voice has a name: It is called unconscious bias, and I will describe this more in section three).

Between them, my first three jobs in software engineering lasted twelve years (four years, then one, then seven). There was one feature that all these experiences had in common: I found it hard to ask questions. When I was struggling with a piece of work, my approach tended to go like this:
  1. 1.

    Try to work it out on my own. I was proud, and hated the thought that people might think I was ignorant – particularly if they thought I was ignorant because I was a woman.

     
  2. 2.

    Stall. If I was stuck and too proud or scared to ask for help, I would simply cease work. Daily stand-ups were unheard of, we worked alone, and we were given large tasks which could last several weeks, so it was possible to do very little work for some time before anyone noticed.

     
  3. 3.
    Ask for help. There were three problems with this approach:
    1. a.

      It meant admitting that I didn’t know what I was doing.

       
    2. b.

      It meant interrupting someone. Everyone always seemed to be very busy.

       
    3. c.

      When people explained things, this involved me looking over their shoulder while they whizzed through complex concepts at break-neck pace. I would sometimes end up none the wiser.

       
     

2.2 Imposter Syndrome and its Effects

For those first ten years, I suffered significantly from self-doubt. I rose to the position of senior developer very quickly, and always got good feedback. I loved writing code and took it seriously. By all objective standards, I was in fact good at my job. But I still believed that most of my colleagues knew more than me.

I frequently suffered from imposter syndrome, i.e. the idea that I was not good enough for the role, and would be “found out”. This is not unique to women – men can suffer from it too – and not all women have it. But it tends to be common amongst women in IT, and it’s not difficult to see why: If you’re part of a minority, you feel like you don’t fit in. Like you’re an imposter.

After those first twelve years as a software engineer, I was made redundant. At that point I had been with the same company for seven years, but my interest in the job had waned significantly. There were several factors at play:
  1. 1.

    I had several times asked to work on the more interesting and complex software, but had repeatedly been denied this opportunity.

     
  2. 2.

    I had started working a four-day week. My best guess as to why I might have been denied the opportunity to work on the more interesting software, based on conversations with other colleagues, was that because I worked reduced hours, I wasn’t taken seriously. People working on the really exciting stuff were expected to work evenings and weekends, and of course five days during the week.

     
  3. 3.

    I wasn’t giving the job my full attention. It was a vicious circle: I wasn’t given interesting work to do, so I focused more on hobbies and family, which meant that I was taken less seriously, which resulted in me paying less attention to my job.

     

So, when I was offered voluntary redundancy, the decision to leave was not hard. In my exit interview, it was suggested I might try being a social worker! This did not appeal to me.

2.3 The Welcoming Environment of XP

By the time I was made redundant, I was very bored of my job. My skills had stagnated so much, that as well as having very little enthusiasm for finding another software role, I doubted my ability to find anything new. As a result of these factors, I left the career altogether.

After four years out of the industry, I realised that I was more suited to software development than anything else. I decided to return. I was honest about my out-of-date skills, and got myself a job with a company that specialised in taking on graduates and training them up. It was a revelation. Because of the emphasis on training, employees were not only encouraged, they were exhorted to ask as many questions as possible. There was no problem with people being too busy to help. Everyone in the company was expected to both ask and answer as many questions as possible.

The teams I worked with had daily stand-ups, where each team member would report on what they were doing and flag up any problems. The company’s design methodology was largely waterfall, but the cultures of communication and collaboration were filtering through from XP working practices in other parts of the industry. This included regular and in-depth code reviews, and an introduction to the concept of clean code.

All of this helped to counter the problems I had experienced before, in the following ways:
  1. 1.

    If I got stuck, I knew that someone would be eager to help me.

     
  2. 2.

    Daily stand-ups meant that there was nowhere for me to hide. If I had problems, I had to admit them. This was liberating.

     
  3. 3.

    My code was regularly reviewed in depth – so that I was always getting feedback.

     
  4. 4.

    The emphasis on clean code meant that I and my peers were focused on making our code accessible to each other.

     

I was now back in the career and enjoying myself enormously. The idea that it was OK to ask questions was exhilarating. It also helped that I had those twelve years of experience behind me, so I no longer felt like everybody else was more experienced than me.

I deliberately made coding my hobby, and got involved in events run by organisations like XP Manchester [3]. This meant that I was learning about such practices as TDD and pair programming. This excited me, and I was able to move to a more XP-focused company. My progress at this point accelerated rapidly. It wasn’t long before I gained the confidence to become a contractor, at which point I moved between several companies on various contracts, and experienced several different implementations of XP.

My confidence increased, but when I felt the old insecurities creeping back in, I decided to approach specific colleagues and ask them to act as sponsors or mentors on my behalf. I also gained the security to discuss the value of positive feedback with my line manager. I have learnt over time that, because of the various insecurities I face as a minority within this profession, I benefit enormously from explicit encouragement. I believe that there is level of openness and communication implicit within XP that has given me the strength to ask for this kind of support.

3 Discussing Lessons Learnt: Attracting More Women Through XP

This section describes the lessons I have learnt as a woman working with XP, and how they might be used in order to encourage more women into XP teams, and enhance the experiences of the women already there. This will include the following sub-sections: The Importance of Diversity Within XP, Stereotype Threat and Unconscious Bias, and finally The Positive Impact of XP.

3.1 The Importance of Diversity Within XP

It may or may not be true that the number of women in XP is a bit higher than elsewhere in the industry, but even if it is, they are still in the significant minority. It’s important that we don’t simply sit back, cross our arms and say “Oh, we use XP. We don’t have a problem with women in IT. We’ve solved that one already.” There is still room for improvement, and XP practitioners have an even greater responsibility than elsewhere in the industry to increase the numbers of women in tech. This is true for several reasons:

XP emphasises the importance of seeing things from the end user’s perspective. This is helped when we have things in common with our end users. Obviously those end users are as diverse as our populations are. The more diversity we have within our teams, the better chance we have of appreciating our end users’ experiences.

Also, XP is a forward-looking movement which emphasises flexibility, change and progress. As agilists, we value individuals and interactions over processes and tools, therefore if there is any group of people (for instance, women) whose ability to contribute towards their teams is compromised in any way, then this should be a matter of importance within the XP community.

3.2 Stereotype Threat and Unconscious Bias

Stereotype threat describes the experience of any group who suffer from negative stereotypes. In the case of women in technology (and also men in the caring professions, as just one other example), these negative stereotypes manifest as a general assumption that they will not have the skills they need to succeed. Such damaging ideas put people under threat, because they constantly feel they have to disprove them.

There is a large body of research which supports the statements I will make in this section. Several examples are referred to in the excellent book Delusions of Gender by Cordelia Fine [4], and I will quote some of them here. For instance, research shows that women’s ability to perform is hampered by their anxiety about negative stereotypes. Instead of being able to concentrate on difficult tasks, a significant proportion of their mental concentration is taken up by trying to quell their fears about their potential lack of ability [5].

My own experience bears this out. I have described in this paper how, after a few years in the profession, I found myself in a job where my requests to do more interesting work were denied. There was always a part of me which believed I was less capable than my male peers, and that it was therefore quite reasonable for those requests to be denied. I decided that I would be better off looking for success in other areas of my life – my family and my hobbies – and that I would accept that my job was simply something whose purpose was to pay the bills, rather than something I could expect to excel at or enjoy.

Another problem is that the more successful a woman becomes in a male-dominated profession, the more she will be affected by stereotype threat. This is for several reasons: The more she moves up the ladder, the more of a minority she will find herself in. This will make her more anxious about other people’s assumptions, but will also encourage her to believe – by sheer force of statistics – that those assumptions are true. “One study found that the more men there are taking a mathematics test in the same room as a solo woman, the lower women’s performance becomes” [6].

The problem is not that girls are inherently less good at technology, or even that they’re less interested; it is that people expect less of them. For instance, some men and women were given a difficult mathematics test. Before they started, they were told that it was designed to better understand what makes some people better at mathematics than others. A control group were told the same thing, but were also told that thousands of students had been tested and no gender difference had ever been found. In all groups, the average score for men was 19 %. In the first group, women also averaged 19 %. But in the second group, women averaged 30 %. Even though gender was not explicitly mentioned to the first group, it did not need to be. They could make that connection for themselves, and their performance was affected. But once that stereotype threat was removed, the potential of the women appeared to be unlocked [7].

As well as stereotype threat, another important phenomenon is “unconscious bias”. This is effectively the technical term for what I have referred to in this paper as an “inner voice”. It refers to the automatic connections that most of us make, for instance between women and the arts, and between men and technology.

One effect of unconscious bias can be that even when women are working within technology, both they and their colleagues do not see them as being in the correct role. This can be particularly true of women doing purely technical roles, such as software engineers. During my own career I have twice faced significant pressure to move out of a software role and into an organisational or management role. Luckily I was quite clear that I wouldn’t enjoy those roles. In both cases I did temporarily make the change, but quickly recognised that I was moving in the wrong direction, and fortunately I had the confidence to move myself quickly back into a technical role.

The good news is that both unconscious bias and stereotype threat can be mitigated against by education. When people become aware that the problem exists, and how wide-ranging its effects are, they can start to do something about it. There are various organisations which offer “unconscious bias” training: this allows people from across a company to become aware of how unconscious bias and stereotype threat affect both the recruitment process and the ability of individuals to progress within the workplace. We are hoping to introduce this at LateRooms later this year.

3.3 The Positive Impact of XP

The inner voice which whispers, “But you’re a girl,” has never entirely gone away. But the following working practices have allowed me to take positive actions to improve my own experience and counter all the problems caused by being in a minority:
  1. 1.

    Daily stand-ups: I have frequently flagged up problems, and the resulting help and reassurance have helped to alleviate any insecurities.

     
  2. 2.

    Team retrospectives: When my team at LateRooms recently experimented with mob programming, we found that we were sometimes getting carried away with strong opinions, which led to some colleagues feeling excessively judged and criticised. We agreed to be kinder to each other as a result. This highlights how effective the culture of the retrospective can be in helping team members who might potentially be discriminated against.

     
  3. 3.

    Pair programming: My skills have improved more quickly since I have been able to pair program. I assume I will always have something to learn. I assume the same is true of my colleagues. Although I may occasionally worry that my male colleagues are more proficient than I am, this is proved wrong on a daily basis when we sit side by side and I see that they learn from me as much as I learn from them.

     
  4. 4.

    Iterative development: The focus on iterative development and a good working relationship between developers and stakeholders allows me to contribute towards a diverse and comprehensive understanding of the context in which my team finds ourselves.

     
  5. 5.

    Communication: The general supportive spirit has given me the confidence to explicitly ask for the support and encouragement I need to overcome any lack of confidence caused by being in a minority.

     

All of these practices should already be present in XP teams, but it is worth being aware what a positive impact they can have on minority groups, and therefore consciously practising them with that in mind.

4 Conclusions

After many years in the industry, I have encountered several problems to do with being a woman. The main problems have centred on my own lack of confidence in my ability to perform effectively in a technical role, and the tendency for colleagues to encourage me away from technical roles. The available literature - and my discussions with other women - would suggest that these are common problems for women in this industry.

However, since I have been working with XP, I have experienced several benefits and improvements. I believe these are due partly to the emphasis on communication and collaboration, particularly in the form of pair programming, daily stand-ups and retrospectives; and partly to the focus on iterative development and a good working relationship between developers and stakeholders. These aspects have given me the opportunity to evaluate my own skills more objectively, share knowledge and both give and receive the support I need. They have also allowed myself and my colleagues to evaluate and act upon any negative experiences within the team.

Clearly the experience of women is important to all workplaces in our industry, whether they use XP or not. But because of the emphasis placed by XP on people over process, and because XP understands the very important relationship between developers, business owners and stakeholders, then XP teams should not only care more about this, but are particularly well-placed to do something about it.

Footnotes

  1. 1.

    I will use the term “minority” to refer to women throughout this paper. Clearly women are not a minority within society, but they are within technology.

Notes

Acknowledgements

This paper was made significantly easier and more pleasant by the involvement of my shepherd, Jutta Eckstein. Her input has always been supportive, insightful and constructive. Thank you also to Esther Derby, Wendy Closson, Arlo Belshee, Philip Brock, and Lisa Crispin for responding to my emails. I would like to thank my employers, LateRooms.com, for their encouragement - in particular my team leader Arwel Griffith and our Director of Delivery, Alastair Brown. And finally many thanks to my partner Ally Fogg, for his input and support.

References

  1. 1.
  2. 2.
    Hewlett, S.A., Luce, C.B., Servon, L.J., Sherbin, L., Shiller, P., Sosnovich, E., Sumberg, K.: The Athena Factor: Reversing the Brain Drain in Science, Engineering, and Technology. Harvard Business Review, Boston (2008)Google Scholar
  3. 3.
  4. 4.
    Fine, C.: Delusions of Gender. W.W. Norton & Company, Inc., New York (2010). (p. 63)Google Scholar
  5. 5.
    Johns, M., Inzlicht, M., Schmader, T.: Stereotype threat and executive resource depletion: examining the influence of emotion regulation. J. Exp. Psychol. Gen. 137(4), 691–705 (2008)CrossRefGoogle Scholar
  6. 6.
    Inzlicht, M., Ben-Zeev, T.: A threatening intellectual environment: why females are susceptible to experiencing problem-solving deficits in the presence of males. Psychol. Sci. 11(5), 365–371 (2000)CrossRefGoogle Scholar
  7. 7.
    Good, C., Aronson, J., Harder, J.A.: Problems in the pipeline: stereotype threat and women’s achievement in high-level math courses. J. Appl. Dev. Psychol. 29(1), 17–28 (2008)CrossRefGoogle Scholar

Copyright information

© The Author(s) 2016

Open Access This chapter is distributed under the terms of the Creative Commons Attribution-NonCommercial 4.0 International License (http://creativecommons.org/licenses/by-nc/4.0/), which permits any noncommercial use, duplication, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, a link is provided to the Creative Commons license and any changes made are indicated.

The images or other third party material in this chapter are included in the work’s Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work’s Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.

Authors and Affiliations

  1. 1.IT DepartmentLateRooms.ComManchesterUK

Personalised recommendations