Applying Agile Concepts to Allyship

Racism in the United States is hard-coded into American society. As a white person who works in tech, I’ve been wondering what we can do to fix this problem. Many of us approach allyship with a waterfall mentality. This shows up as large-scale bursts of allyship, carefully planned and infrequent. Even when well-intentioned, these acts seem performative and reactive in nature. True allyship looks different. It’s not a one-time release. It’s continuous.

What if we took the concepts behind agile and applied them to allyship? What would it look like? 

I know it’s a leap, but bear with me.

1. Our highest priority is to dismantle systemic racism through early and continuous delivery of allyship.

What is the earliest moment at which a company could deliver allyship? Many start-ups begin with a person who can code and a person who can sell. By that measure, early allyship needs to start with both the product team and the sales team, from their earliest days.

Then, tech companies figure out what types of customers they want to sell to in the first place. For example, a B2B software company could specifically prioritize selling to minority-owned companies, which tend to grow faster anyway. That isn’t a very common strategy today, but perhaps it should be for any company that uses an agile approach to allyship.

Here’s another possible example of early allyship. Many tech employees receive an orientation on their first day of new hire training that explains how they can contribute to their company’s 401K with company matching. What if software companies enabled employees to set up deductions from their paycheck that would go directly into a fund devoted to ongoing allyship? What if these were set up on day one of the new hire experience? This would be an example of how allyship actions could be systematized, automated and delivered early and continuously.

I realize I might be venturing into tricky territory by suggesting that we could make it possible for people to deliver allyship without even thinking about it. But isn’t that what we do every day when we carry out acts of racism unintentionally, by simply being part of a racist system? Do we know where every dollar goes from retirement investment accounts? Most of us do not. Are any of those funds ending up at businesses that support white supremacy? They might be, actually, and we probably don’t even know it. We might be contributing to systemic racism without knowing it, every day. 

So, what if we could enable people to contribute to allyship causes without knowing it too, continually, on top of all the additional work we need to do as individuals? I’m not suggesting people sidestep the hard work that goes into inner change, but I do think we could also give people additional ways to deliver meaningful, ongoing and automated allyship that could make a real impact. 

2. Welcome changing requirements, even late in allyship initiatives. Agile allyship harnesses change for the advantage of those it supports.

Our allyship efforts need to be ever-changing and moving along with changes in the societies in which our businesses operate. We need the ability to react and respond to timely events continually, to match the pace at which it’s happening. As one example, what if we had a simple stream that would prompt people working in tech to take one daily allyship action, each and every day? These could be configured (by humans of course) to map more closely to ever-changing needs and groups in pressing need of urgent allyship.

All I know is that it would be great to put allyship opportunities in front of people daily with small actions they can take more frequently that are meaningful. I’m not sure what format it should take exactly, but I do believe we could create a system that enables processes and structures to emerge that are more likely to enable allyship than those which enable racism. On the contrary, if we don’t do that, we won’t make traction fast enough to keep pace with the changes in society happening all around us.

3. Deliver allyship actions frequently, with a preference to the shorter timescale.

All of us who ever took a marketing course know that many exposures to a message will help get it across much more effectively than a single big campaign can. Could the software industry put our digital marketing and SEO talents to work in order to make this happen through continued and repeated exposure to messages in support of allyship? Awareness-building isn’t something that should revolve around just specific events. We need to keep the message in front of our industry and all who work in it, on a continual and ongoing basis.

The original principles of agile state that these actions should be weekly or monthly. I believe the true need for people to take actions of allyship will be daily, at a minimum. It’s going to take large numbers of people, taking constant micro-actions of allyship daily, if we ever hope to make a dent in the huge volume of micro-aggressions our colleagues of color face daily.

4. People from diverse backgrounds must work together daily throughout the project.

Progress toward diversity and inclusion efforts can be difficult to measure. Even if you know that you’re hiring people from more diverse backgrounds, you don’t necessarily know how well they are being included by all teams and people they work with, and how well they feel they belong in your company and in the software industry at large.

What if we tried to measure how many people in software report that they work daily with a person from a different background than their own? What if software companies measured this continually and took it as seriously as we do CSAT and NPS? What if shareholders and investors demanded to see this too, and based investment decisions and valuations on this metric to some degree? This concept could be an interesting way to measure our collective allyship progress within the software space. At the very least, it could be a leading indicator.

5. Build allyship projects around motivated allies. Give them the environment and support they need, and trust them to get the allyship job done.

Allies should be the ones to lead allyship initiatives so that the people most affected do not have to. Already, the people who belong to the groups that would-be allies seek to support are the people doing 99.99% of the work at most software companies, on top of their normal jobs. That simply isn’t fair.

I wonder, if we explicitly state that it’s up to those who would seek to earn the title of allies to do this work at software companies, how we could transform things. What if we make allyship engagement a default expectation for employees? What if we created recognition awards for meaningful and continual actions of allyship in software? Perhaps it would motivate people differently, create teams that perform better, and would lead to better overall business outcomes too.

6. The most efficient and effective method of conveying allyship to and within a team is face-to-face conversation.

This also struck me as something we could measure. Have you had a conversation with a person who identifies differently than you do, face to face (albeit via Zoom), in the past week? How does your team compare to another? How did you score companywide last quarter versus this quarter? What is the industry benchmark? And how do we enable more of these to happen? 

This could be another possible measure of progress or perhaps a leading indicator of how well we are doing at actually getting people working together, knowing people as people, building better teams with higher levels of trust, and hopefully appreciating differences in the process. 

7. Active allyship is the primary measure of progress.

This too struck me as as an engagement metric in allyship initiatives that we could easily measure, if only we can do a better job at systematizing more allyship actions. How many employees are engaged in the “allyship payroll deduction” concept mentioned previously? How many have engaged in one of our daily allyship actions? What is our allyship engagement score? 

It wouldn’t be tricky to get digital marketers to help measure this either. Each allyship action has a landing page. From there, we could track the overall percentage of people who click on the pages and participate. We could report on our progress, measure it monthly and share it transparently. 

To see true progress that we could measure, allyship would need to be intentionally built into our processes and systems. Otherwise, we can’t dismantle systems that currently have racism hard-coded into them.

8. Agile processes promote sustainable allyship. The sponsors, allies, and communities should be able to maintain a constant pace indefinitely.

Small actions that are continuous are great in that they are truly sustainable, unlike huge actions that take tons of planning before one can see any impact. Making allyship more sustainable would enable us to ensure constant and continual allyship actions, versus inconsistent ones that run a very high risk of being performative and too infrequent to matter.

9. Continuous attention to technical excellence and good design that enhances continuous allyship.

The software industry has a lot more work to do here. We often build products so quickly that we don’t always pay attention to things like gender-inclusive language and design that is free of bias from the beginning. We don’t always create things in a way that will ensure success for people of diverse backgrounds and abilities. 

But taking it a step further, do we continually think about doing things when we build products in a way that directly enables our users to engage in allyship with even small, almost invisible and automated actions they can take within the products themselves? For example, CMS developers, what if we analyzed the distribution of representation of faces in images on websites people are building to see if they appear to be appropriate for the audience they want to reach? What if we reminded people of the importance of checking on that, as a default option in the software we build? 

CRM and marketing automation companies, what if 70% of the names in a user’s contact database are typically associated with females, but the user is about to send them an email that only has images of men? Should we warn them of this audience and message mis-match, if we technically can? Wouldn’t they like to know that ahead of time? Isn’t it possible that not knowing is hurting them too? What if we could empower allyship in each of these UX moments instead? Wouldn’t it be a better experience for our end user too?

10. Simplicity – the art of maximizing the amount of work not done — is essential.

Here, I would ask software companies to take a hard look in the mirror and ask themselves if the vast majority of their efforts toward allyship currently have any real impact. If not, it might be time to take inventory and ask ourselves what we could be doing instead for allyship, if we stopped doing those “waterfall” things that take tons of time to plan and don’t seem very impactful. What will have the most impact on allyship, and enable us to deliver it earlier and more continuously? Doing this exercise with an agile perspective might actually help us simplify and change our model to focus on continuous delivery instead.

11. The best allyship emerges from self-organizing teams.

This is true in software, but also with regard to allyship. You can try to get employees excited about something you want them to do for allyship, but it only really matters to them if they are part of building those initiatives themselves. It has to come from within in order to succeed. Many people in software feel personally motivated to move the needle on allyship. Is it possible they feel they don’t have the permission or autonomy to do so? Is it clear their allyship efforts are welcome?

12. At regular intervals, the team reflects on how to become better at allyship, then tunes and adjusts its behavior accordingly.

Just like stand-ups and post-mortems, constantly re-examining how we are doing is a part of agile allyship. It’s the only way to flag when we have introduced painful bugs, fix them, and move on and keep building. Agile allyship offers us plenty of opportunities to fail and grow, but only if we’re reflecting continually too.

Closing Thoughts On Changing Our Allyship Delivery Model

I honestly believe that the move from waterfall to agile principles and CI/CD in software has transformed people’s lives, because it truly changed the way we build software and helps us to make more frequent and transformative impact. Agile helped us create a new system and in the process, start making a less impactful one fade out.

Similarly, the big, carefully staged, waterfall releases of allyship we are guilty of at software companies today are just not helping, and not really a great fit for modern times.

We need a better system, a different way to have more allyship impact, more frequently, if we really want to create transformative, lasting change and dismantle systems that enable racism to exist in the software industry.

Whether we decide to lean on the agile principles that have served us so well to build software or not, it’s clear that we all need to move toward an entirely different and more sustainable model of allyship — in our lives as individuals, in our teams, in our companies, and in the tech space at large.

Nataly Kelly

Nataly leads localization at HubSpot and has previously held diverse roles in marketing, international operations and strategy, research, and product development. Her latest book is "Found in Translation" (Penguin). She writes for Harvard Business Review on topics of international marketing and global business. Nataly works remotely from New England, having lived in Quito (Ecuador), Donegal (Ireland) and the rural Midwest where she grew up.

Leave a Reply