Can Agile Methodology Unlock Diversity?
Over the past decade or so, there’s been a lot of research showing that diversity improves innovation on teams of knowledge workers by bringing together unique perspectives and non-traditional approaches that are the result of unique skill sets, experiences, and complementary knowledge. Diverse groups are more likely to represent important constituencies, bringing valuable insights from the external marketplace into the workgroup. And diversity therefore improves the bottom line for businesses.
And yet that’s not necessarily always true. Increasing the diversity of your teams does not automatically lead to better team productivity or innovation. Shifting from a team of individuals who all have a similar educational, age, gender, racial, and class background to a team comprised of individuals from different ages, genders, racial, class or other backgrounds, can cause increased misunderstanding and frustration and therefore reduce productivity. Language barriers, different communication styles, different expectations and different ways of approaching problem-solving can arise when you bring together a diverse set of individuals in a team. Diverse teams can also spend so much time trying to find commonality that they compromise on their unique perspectives in order to gel as a team.
As a non-American woman of color, I have experienced this sort of communication break-down and the resulting sense of alienation — especially in my first few years of living in the United States. At college and then in law school, it was rare for me to find myself amongst people with whom I could speak and act both directly and in subtext (the unsaid, implicit understanding that can exist between people of similar backgrounds), and be fully understood. Instead, I had to learn the subtext of the majority population, and the energy I put into that learning often left me quiet — listening instead of participating.
After thirteen years in the United States, I can mostly speak and act the subtext of the majority, and I feel almost completely comfortable searching for and finding commonalities with most people, no matter their background, age and gender, because my job requires that skill.
I know that’s not the experience of many who work in the tech industry, and in my role as a Diversity & Inclusion Manager at Symantec, I have encountered many individuals who find themselves in the minority on their teams and unable to contribute to their fullest because they don’t speak the same subtext or have the same informal networks as the majority members of the teams do.
So how do we unlock the potential of diverse teams? To truly leverage diversity within teams, I believe they need to function in a manner that actively fosters open communication & dialogue, they need to come together around a set methodology for working together, and to prioritize different perspectives as input during the process.
I believe we have a formula for such inclusive behavior in the agile methodology.
It might seem ironic to look for a solution to Silicon Valley’s diversity problem in the methodologies used by the Valley’s least diverse teams. While I believe we can adapt certain aspects of how teams work in tech to create inclusive cultures, I also believe that this sort of inclusive behavior must be coupled with other intentional diversity efforts (i.e. recruiting diverse team members), and with other efforts at creating inclusive workspaces (e.g. designing your physical workspace and extracurricular team activities to be inclusive).
Agile Methodology — A Brief Overview
Here’s how agile works on scrum teams (to go more in-depth, I recommend Atlassian’s resources on agile methodology). In this post, I use the scrum variety of agile as an example because it’s used about five times as often as other variations.
In scrum, you’ve got three roles:
- The Product Owner, who understands the customer’s needs and creates a plan — a product backlog with the team (a list of tasks that need to be completed) that can be broken down into “sprints” or shorter chunks of work from this backlog
- The Scrum Master, who does whatever it takes to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint
- The Development team are the designers and engineers that create the product
Together, they all make up the scrum team.
Scrum calls for four ceremonies that bring structure to each sprint:
- Sprint planning, where the product owner, scrum master and development team pick up parts of the backlog to work on (a chunk of work that’s do-able in two weeks)
- The daily stand-up, where each day, every member of the scrum team spends 1–2 minutes talking about what they’ll do today, and mention anything they’re blocked on
- The sprint review, where the team get together to informally review and celebrate a piece of work done or a milestone reached
- The sprint retrospective, where the team talks about what went well and what didn’t during the previous sprint, so they can improve their processes.
Agile Inclusion
While the agile methodology is mostly used on engineering and software development teams, it has started to spread beyond technical teams to non-technical ones as well.
There are certain key tenets of agile methodology that lend the process more to inclusion than more traditional waterfall/hierarchical organizational structures:
- Valuing individuals and interactions over processes and tools is key in agile methodology and more time is therefore invested in making sure the team gels and communicates well
- Fast iteration requires immense trust and openness. Agile teams dedicate resources (a scrum master, for example) and time (daily standups & retrospectives) to building openness and fostering trust
- Prioritizing responsiveness to change calls on teams to draw on members’ unique perspectives to problem-solve in the moment. This bakes the desire for diverse perspectives into the vision of agile teams.
Below is a non-comprehensive list of practices of Agile Teams that I believe would benefit diverse non-engineering teams as well as diverse engineering teams (if coupled with other essential D&I efforts — more on this at the end).
Structure
Scrum teams are, by design, cross-functional but tightly knit. In order for a sprint to be successful, teams need to work closely together, bring diverse perspectives to the development process and help and mentor each other. This is encouraged in agile teams as an essential tenet.
Creating a dynamic where individuals are highly reliant on others within the team for their own success is a risk, especially with diverse teams, as the possible communication breakdowns mentioned earlier can greatly impact productivity in the short term. The benefit of creating this high dependency situation can be, however, that individuals are forced to overcome communication and work-style barriers in order to deliver on their team goals, and that shared short-term goals in an iterative process brings members together to form a new “tribe” of affiliation and affinity.
Rewards
Each task in the backlog is called a story, and at Symantec, the completion of each story comes with rewards in the form of points. As a team, you get points if you finish a story in your sprint. These points go towards rewards.
Incentivizing teams in increments is an effective way of boosting morale, especially as a counter to any friction or tension that arises from having different work styles on a diverse team.
The Daily Standup
Scrum teams meet once a day for no more than 15 minutes to share what they’re working on, and what they’re stuck on, if anything. Fellow team members offer to help if they can, or offer advice if needed.
A daily standup ensures both transparency of each individual team member to the group around the work they’re doing, and accountability. All team members are working towards the same goal — completing the sprint successfully — and if one member falls, everyone falls. It is therefore everyone’s job to ensure that every team member is functioning to their full potential.
Introverts are given the space to speak within this structure, and if someone is blocked and says so, other team members have a chance to jump in and help.
Scrum Masters
A scrum master is the champion of the agile process within a team.
According to Atlassian, “An effective scrum master deeply understands the work being done by the team and can help the team optimize their delivery flow. As the facilitator-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.”
On diverse teams, having a facilitator that enables each individual’s maximum productivity could mean the difference between dysfunction and miscommunication, and a harmonious team, inclusive of all perspectives and input.
Scrum masters will call on individuals to help a team member blocked on a certain task, for example, as the scrum master knows each team member’s strengths.
What if we had a scrum master, or an equivalent “unblocker” on every team within an organization? This role need not be a full-time position but could be assigned to one individual on the team and could rotate on a quarterly basis, for example. When individuals feel they are responsible for overseeing team inclusion practices, even if only for a few months, this might instill in them a consciousness and intentionality around this behavior that lasts beyond their turn as team unblocker.
Project Tracking
Using project management tools is a must for technical teams practicing agile. With so many small teams working on small chunks of work, a software that enables the tracking of all these moving parts is essential. What if tech companies expanded the use of these project management tools to all teams, not just technical?
In Jira, a Symantec engineer told me, every story you track for yourself can be seen by your colleagues, managers, all the way up to your Senior VP. This kind of transparency ensures better productivity, but also has some unforeseen benefits. Introverts, for example, can ask for help by posting their issues on the team board, instead of bringing them up in a standup.
Providing team members multiple avenues for expressing themselves is a best practice from agile that could shift how well we leverage the quieter members of teams’ perspectives in other realms too.
The Retrospective
Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well, and what didn’t. This sort of self-reflection by teams, looking at their own dynamics, is key to uncovering blockages that might be at play in the team. To truly succeed at retrospectives, scrum masters play a key role in facilitating the dialogue and digging out the root causes of issues during the last sprint, so that the team can together modify and improve their working dynamics.
In teams that are not structured to perform iteratively on smaller chunks of larger tasks, a retrospective at the end of larger projects that looks not just at how well the project went, but looks at the behavior of team members, could raise important issues of inclusion or lack thereof.
Agile ≠ Diverse
I do want to note here that teams adopting agile methodology do not become diverse. Most agile teams at tech companies, look something like the cast of HBO’s Silicon Valley.
In fact, the inventors of the agile methodology were ten white guys. I’m going to venture to say they weren’t thinking about diversifying computer science when they created the methodology - they were thinking about efficiency and productivity.
What I’m talking about here is this: with a diverse team (whether in a development or a non-development environment), introducing some best practices from the agile methodology may improve inclusive behavior, thereby “unlocking” the diversity on the team — the potential that comes with different perspectives, different work styles, different personalities. What Agile Methodology cannot do is create the team diversity in the first place. There are many strategies and tools an organization can utilize to increase the diversity in its teams. Some of those will be the subject of my next post.
In the meantime, tell me what you think of the idea of Agile unlocking diversity — have you seen inclusive behavior increase as your team has shifted from waterfall to agile? Do you see pitfalls of Agile for inclusion on your teams? What are they? Has your organization already begun thinking of agile inclusion? How is it working for you?
About the Author: Ruha Devanesan is a Manager of Diversity & Inclusion at Symantec, where she works with the Chief Diversity Officer, Symantec’s Human Resources teams, the Executive Leadership Team and diversity champions throughout the company to bring balance and inclusion to the company’s workforce.
