Globally women in IT are a minority and there is a focus to improve gender diversity at workplace. IT departments practicing agile are no exception to this. This paper outlines my experiences that I had over my 10-year journey as a woman agile practitioner in India. The paper will address three key problems across time zone, forums and skills that I have seen more prominently faced by women working in agile teams. Addressing these problems helps to create an ecosystem that will aid not only women but also the whole teams to excel.

1.     INTRODUCTION

We all see the momentum around us to encourage diversity including gender diversity. For the past decade, I have been working for companies that in one form or another champion improving the ratio of women at the work place as one of their focus areas. This past decade is also when companies have adopted agile way of working in a big way. When I reflect on my decade long tenure in agile, I ask myself – Does agile help when your voice is in the minority? Can practicing agile give women courage and avenues to express their opinions at workplace? What does the new momentum towards digital initiatives mean for women in Agile?

In this experience report, I would like to describe some techniques that I have coached to deal with the challenges that women faced. The experiences that I have outlined are those when working with IT services providers and their clients. I do understand that some of the ideas in this paper are highly subjective and others may not have encountered the same.

2.     BACKGROUND

My introduction to agile was purely accidental. In 2008 I was working with a large IT service provider in India. Our client was one of the Fortune 100 enterprise clients. My program team had planned the program as waterfall but then the client requested scrum. The program had only a handful of women – I, in the role of scrum master and several BAs. We did a program level retrospective 6 months into execution. When we collected the data points for improvements, I realized that most of the implemented improvements were something that I had suggested. I wondered why that happened. It dawned upon me that there were now avenues for me to express my views – ceremonies like Scrum of Scrums and sprint retrospectives. Earlier in waterfall world, my voice drowned in other male dominated voices. Such instances built my hypothesis that agile was helping everyone come on the same level and make their voice heard. It strengthened my resolve to continue with agile and help more women and teams adopt it.

As I went along the agile journey, I realized while agile does help, it is not enough. An effective ecosystem is needed for the women to excel when using agile techniques. As I dug deeper around this area, some of the industry data supported my observations [2]. For example: Regularly, Nasscom, which is a trade association of Indian Information Technology (IT) and Business Process Outsourcing (BPO) industry, does a report on “Women and IT Scorecard-India” [1]. For their 2018 report, 55 companies were surveyed. The sample includes small (<1001 employees), medium (1001-5000 employees) and large and very large (>5000 employees) organizations. The table below shows the constraints that IT professionals (male and female) in in India face during recruitment. The 4 common constraints faced predominantly by females are:

1. Need for safe transportation to and from work.
2. Break in career for family needs
3. Parental leave and managing changes in working patterns after maternity
4. Conflict with need to juggle personal and professional commitments.

Table 1: Perceived constraints for recruitment in the surveyed firms (Percentage of firms responses) – Nasscom 2018 report [1]

3.     MY STORY

After playing scrum master role in 2008, I gradually moved on into agile coaching. I started helping the other teams, their scrum masters and then 3 years down the line switched to full time agile coaching. As I switched into coaching, I started observing the behaviors and people dynamics closely as that could make or break the agile adoption. The team members came from various parts of India with diverse backgrounds. Due to the fact that perhaps I was one of the few women agile coaches around, I found women opening up and sharing their challenges with me. While the women did come from diverse backgrounds, there were some common threads that used to crop up in most of our conversations – The talks usually revolved around topics of family, handling the office commutes and not able to find time to learn anything new. It struck me that at times these topics were in fact becoming a hindrance in the agile adoption and we had to do something about it soon. Here are 3 anecdotes highlighting this aspect.

3.1        Anecdote 1: Time-zone: Uneven distribution of women in teams due to time zone issues

I had the responsibility of driving agile adoption for one of our large clients from the financial domain (we had over 500 team members working for this client across US, Europe and India).

It was about 4 months into the agile adoption and a woman scrum master – Monica, approached me. She told me that she was resigning and taking on a developer role in another company. I probed Monica to understand the reason as I felt there was more to the story. It came out that indirectly the agile way of working had influenced her decision. Monica had to work in non-core India hours for agile ceremonies. She was increasingly finding it difficult to balance her commitments towards her home and her in-laws. I asked her not to take a hasty decision. I promised her that I would talk to the clients to check on enabling remote access for team members working from India locations. When I spoke with the client, the client expressed inability to provide this access as this decision was with their security and risk department and not theirs. I tried to point out that team members only needed basic access to emails and not complete access to all the systems. I also pointed out that my team members who were at US locations for the same project had work from home capability. The client still expressed inability, as it was not within their control. Eventually Monica quit and took on another job.

Societal obligations and ethnic culture trumped agile culture – and in this case we ended up losing a talented woman from our team.

Six months later one of our agile teams called Cosmos working for this same financial domain client was facing a complaint. The client had escalated their concerns to the management about this team. The concern was that the Cosmos team members were not opening up in meetings and retrospectives. They used to wait for the scrum master before doing anything. I knew that this team was difficult to handle and needed someone empathetic to work with them on the ground. Natasha who was a scrum master with my European portfolio was the perfect answer to handle this escalation. She had demonstrated creative techniques to drive self-empowerment behavior within the teams.  Everyone loved her work and clients were very happy. Natasha had been asking me to give her challenging opportunities and this could be the perfect opportunity for her.  I approached Natasha asking her to take up the role for Cosmos team. To my surprise, she refused to take up this role. Her argument was that Cosmos team’s Product Owner was in the US. Her current Product Owner was in Switzerland. If she took up the role in Cosmos, she would have to interface with the team during US working hours. This was a challenge as she drove her scooter to work and was not comfortable riding it back in late evenings. I decided to check with management to see if we could provide pick-up and drop-off cab service for Natasha. By the time I was able to procure the necessary approvals it was too late. The client by then had decided that from the next phase onwards, the majority of the work done by the Cosmos team would be done by their own team in-house. This resulted in ramp-down for the Cosmos team in India and loss of revenue for our company.

Safety concerns led to more women requesting to be associated with projects that had European clients. The time difference between India and Europe is smaller so the agile ceremonies ended during reasonable hours. Women could completely avoid late night commutes that put them at risk and did not need to travel back home during late India hours. This led to uneven distribution of women across various project teams and at times a completely unbalanced gender ratio.

What we did: Instances such as this led us to take a close look at how we could make the overall agile environment more conducive for women. We involved the HR team and worked with them to have sessions and counseling for women employees on balancing their personal-professional commitments. We also brought in a pick-up and drop-off cab service for safe trips back home in late evenings. More importantly, we worked with our client stakeholders such as their IT director, Security, Risk and, Network infrastructure departments to make work accessible to team members in India. For example: opening firewalls so that team members could work from home if the need arose. We could thus nudge the client in a positive direction and we ourselves took steps to keep talented women involved in agile projects.  Slowly and steadily, the gender ratio improved for both – the teams working with US clients as well as those with European clients.

3.2        Anecdote 2: Forums: Insufficient avenues for women to open-up and express their views

To encourage collaboration and acquisition of skills necessary for cross-functional agile teams, I decided to adopt initiatives like open workspace and pair programming. As seen in any situation, there were some skeptics in management and they wanted to understand and experience the benefits before committing to the investment of changing the physical layout. One of our teams working with our retail domain customer volunteered to be the guinea pig for this pilot. This project was a good candidate as it had new technologies that the team had to learn quickly on the job. It also had need for frequent collaboration as we were overhauling the complete user experience and we had committed to deliver the minimum viable product (MVP) in 5 months.  I was the coach for this team and there were 4 other scrum masters – incidentally all male. The team had an overall acceptable mix of gender diversity.

We converted our two large conference rooms into a makeshift work area where the teams could collaborate together. There were also coffee chat opportunities where team members across different levels could engage with management and senior coaches to express their concerns. In spite of this, we received mixed feedback from the team on the collaborative way of working. I failed to understand why this was happening because when I was with the team it seemed that everything was indeed going well. Retrospectives and coffee chats also did not yield anything alarming. I then decided that it was time to take anonymous feedback from the team.

What we did: We designed surveys where team members could provide anonymous suggestions and views. It brought out hidden problems. For example: the following issue was uncovered as a result of the survey. During pair programming, female engineers coming from conservative backgrounds found it uncomfortable to do pair programming with someone of the opposite gender as the work place felt too close for comfort. Since their scrum masters were male, they did not open up on such issues with them and kept this issue to themselves. Pair programming usually requires frequent pair switching. Rotating pair partners and having an open plan collaborative work place causes a rapid spread of project knowledge and optimizes the chance for team members to learn from each other. Due to the issue, it affected the way the team did pairing amongst themselves. Women on the teams were reluctant to pair or switch pairs. They used to always look to pair with another woman or preferred to code alone. Based on this insight, we looked at different ways of organizing our makeshift work area – (a) we changed the layout of the desks, and (b) brought in dual monitors so that people did not feel that their personal space was invaded. After these changes were made, the pilot was a resounding success. Based on the results of the pilot, we were able to secure funding to change our entire workplace to suit the agile way of working.

Today I regularly use surveys as one of the coaching instrument along with normal forums and coffee chats. This gives me insights that normally would not have surfaced.

3.3        Anecdote 3: Skills: Adapting to core engineering work

For the past 3 years, I have been partnering with teams involved not only in agile but also developing digital solutions for our clients based on cloud-native [4], agile and devOps principles. These teams are staffed with architects and engineers having full stack skills [6]. The term “full-stack engineers” as defined by Hackerrank [5] refers to being an effective and seasoned generalist: someone with a wide knowledge base, a solid specialty, and the willingness to admit when they’re out of their depth. For us, the full stack engineers on our teams needed to have skills with micro-services, containers, continuous delivery pipelines and have working knowledge of both front and back-end technologies. When I started with these teams, it seemed to me that I had taken a walk in the past. There were less than 10% women in the senior engineering roles like cloud architects and devOps architects. On one hand, I was having conversations with my clients around full stack teams; on the other hand the women at senior levels in my teams were primarily in roles of scrum masters or UX experts. If you look at the articles and surveys which list the top emerging jobs in technology companies, most of these jobs are those that need core engineering skills [3]. We were also trying to make a conscious effort in the organization to improve diversity in core engineering areas, but it was difficult to find the right candidates due to lack of women with the necessary qualifications and experience. When I spoke to the engineers in my agile teams, irrespective of the gender they expressed their fear of “being left out”, if they did not acquire the full stack skills with cloud and devOps quickly. It was clear that we had to set up skill-uplifting programs to equip the team members with right skills for the future.

 

Figure 1: Top skills for the top 5 emerging jobs India by Linkedin [3]

 

What we did: In collaboration with internal training team; programs for acquiring full stack skills were set up. It is open for both female and male employees across all levels. The structure of the program allows you to do it while you are on the job. The duration of the programs spans from 4-6 weeks to 4-6 months based on the areas that you specialize in. Team members can also form their own study group while taking up this training program to encourage peer-to-peer learning. The feedback received from both men and women team members so far have been positive. Women especially found the study group concept useful as it helps them connect with other women who might be undergoing similar challenges to adapt to engineering skills. To ensure dedicated focus for upskilling, we had “People” epics (similar to business and technical epics) on the backlog. Having epics designated as “People” epics made sure that training and skilling related activities remain on everyone’s radar and do not get pushed out due to other deliverables that the teams may have. Here is an example of People Epic that we had:

“Title: As a digital team, we want to upgrade our cloud and devOps engineering skills this quarter so that we are better positioned to serve our client needs

Acceptance Criteria: 20% of team members have undergone the full stack engineering enablement program

Type of Epic: People

Priority: High

Number of Associated User Stories: 4

Status: In Progress”

In addition to this, to motivate employees along their learning journey and make it collaborative learning, the program was augmented with various initiatives listed in the figure below. “SheInspires” was specifically targeted towards women. In this initiative, women who have completed the program can share their learning experiences with other fellow women. They can also volunteer to be a mentor for other women who were on this learning path. There is also reward and recognition program for those who complete the program with good results.

Figure 2: Initiatives to motivate the learners along his/ her Full Stack learning journey

4.     WHAT WE LEARNED

Lesson 1: Time-zone: Need to create ecosystem where the company management and clients work together and ensure that diversity is their joint concern. While the company may have diversity as top priority, their clients may not be ready to make the necessary changes to enable accessible work options. This may lead to a step back in the diversity efforts.

Lesson 2: Forums: Need to provide various avenues for teams to open up. Team members, especially women may not voice their true feelings in regular forums. Explore different avenues such as anonymous surveys or bringing in women facilitators for some duration to help the team open up.

Lesson 3: Skills: Today the number of women with STEM qualifications in IT companies is fewer than the number of men. To ensure that the skills of those in the organization remain relevant in the future, investment is needed in upskilling programs aimed at women.

5.     ACKNOWLEDGEMENTS

Special thanks to my colleagues Aruna Chandrasekaran and Swapna Namjoshi for being my sounding board. Thanks to Margaret Fogel, her great shepherding helped me to convert my muddled thoughts into a readable experience report. Finally, all the fellow women agile practitioners with whom I have worked over past 10 years. Without them, this experience report would not have seen the light of the day.

6.     DISCLAIMER

The views represented in the paper are solely of the author and do not represent those of the employer or the clients (referred as organizations henceforth) she is associated with. The information contained and the references made in this paper is in good faith and neither author nor her organizations give any warranty of accuracy (whether expressed or implied), nor accepts any liability; as a result of reliance upon the content including (but not limited) information, advice, statement or opinion contained in this paper. This paper also contains certain information available in public domain, created and maintained by private and public entities. The author or her organizations do not control or guarantee the accuracy, relevance, timelines or completeness of such information.

REFERENCES

[1] Nasscom, Women and IT Scorecard, https://www.nasscom.in/knowledge-center/publications/women-and-it-scorecard-%E2%80%93-india

[2] Kanna, Geetha, blog, “Indian Women in Technology Face Unique Cultural Obstacles.” https://anitab.org/blog/indian-women-in-technology-barriers/

[3]LinkedIn, online report, “Emerging Jobs in India.” https://business.linkedin.com/content/dam/me/business/en-us/talent-solutions-lodestone/body/pdf/Emerging_Jobs_Report_India_Sept2018_v3.pdf

[4]Ibryam, Bilgin, online article, “Cloud Native Container Design Principles.” https://dzone.com/articles/cloud-native-container-design-principles

[5] Hackerrank, blog, “The Strange Politics of ‘Full Stack Developer.’” https://blog.hackerrank.com/full-stack-developer/

[6] Shropshire, J., Landry, J., Presley, S. “Towards a Consensus Definition of Full Stack Development,” Proceedings of the Southern Association for Information Systems Conference, Atlanta, GA, USA, 2018.  https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1032&context=sais2018