What Agile Software Development Can Teach Us About Diversity and Inclusion
I write this article as a wave of protests has swept across the nation, leaving us all thinking about how we will resolve some of the most intrinsic problems of our society. While I've previously written about the need for gender diversity, I'm approaching this topic based on my experience as an engineer and technology professional.
The field of software development has transformed dramatically over the last 20 years. What started as a field of separate, isolated units has now evolved into a melting pot of time-boxed units. So how has it changed and what lessons can we apply from this history to our current context?
Software Development: A Walk Down Memory Lane
The process of software development began as exclusive, segregated segments, worked in phases and then passed on to the next team until the product was finally deployed for users. At each point in the process, a group of professionals handled the product — requirements engineers, developers, testers and operations professionals — but they rarely interacted with each other. Each group did their job in a silo and then handed it off to the next group.
This method of software engineering is better known as the waterfall methodology. Dr. Winston Royce first defined waterfall in a 1970 paper about inefficiencies in large software development projects, but no one individual is credited with creating the methodology. Waterfall is still used in parts of the industry despite its well-known disadvantages. Since waterfall doesn't allow for much reflection or revision — an imperative in an ever-changing world — it introduces a high level of risk and requires building a lot of contingency into the schedule, leading to expensive and drawn out projects. In the case of large-scale implementations, by the time the project is put into production, the software and requirements are often already outdated and need to be upgraded.
More significantly, waterfall lacks the insight of every part of the software industry. While developers code the software, they are unaware and fail to consider the issues testers face, thus leaving out significant operational insights in production. This siloed, segregated approach leads to clunky, expensive and often buggy software which requires expensive and prolonged updates.
So how has modern software development changed traditional methodologies?
Related Article: DevOps and the Culture of Inclusion
How Modern Software Development Evolved
Modern software development uses the same principles as agile teaming, where all players in the software development lifecycle are part of one team. Agile teams include requirements engineers, developers, testers, operations professionals, as well as product managers. Inclusiveness is encouraged and the focus is on building small workable code sets which can be swiftly developed, tested and delivered. No group works in isolation, and sharing professional opinions is encouraged and made part of the process. Inclusion isn't limited to the people involved in building the software but extends to users as well. As part of agile teams, product owners and business professionals provide direct user insights throughout the build process.
The push to agile software development has led to increased client satisfaction, better code quality and greater speed.
3 Secrets to Accelerating Transformation to Improve CX + EX
Learn about force multipliers that will reduce technical debt and grow revenue while reducing costs
Why Knowledge Management Is Critical to Business Resiliency
How Organizations are Future-Proofing Business by Harnessing Company and Employee Knowledge
Power Hybrid Work With Tech That Connects
Robin recently surveyed 300+ professionals to better understand what great leadership looks like in a hybrid world.
Digital Mental Health Support: Helping Remote Workers Fight Burnout and Loneliness
The New Era of Well-Being: How to Realize Your Potential and Succeed at Work & Life
Related Article: How Companies Can Bake Diversity and Inclusion Into Their DNA
Lessons in Diversity and Inclusion From the World of Software Development
As a software professional who has grown from development to large-scale IT implementation, I see how the history of software development has taught us lessons in diversity and inclusion if we delve a little deeper. We have learned that:
- Building a higher-quality product requires input from everyone who is involved in the process — from the people developing it as well as those who will be using it. Thus, whether we are building an organization or a nation, the input of every individual is equally significant.
- A segregated approach where multiple stakeholders are not collaborating leads to an inferior quality product. When people in an organization or nation are segregated, the society as a whole is poorer for the practice and we lose out on the richness of multiple point of views and thought processes.
- When groups work in isolation it slows down the introduction of innovation and new practices. Homogenized groups tend to lean on the same ideas and rarely introduce new thought leadership introduction or think outside the box.
Related Article: The Future of Work Requires Inclusion
Next Steps: Better Organizations and a Better World
A mounting amount of data and research supports these findings. However, we still live in a world where diversity or lack thereof remains a major issue, even in tech sectors where data research and experience point all in one direction.
According to Gartner, only 36% of diversity and inclusion (D&I) leaders said their organization was affective at building a diverse workforce. Gartner research also found 80% of organizations rated themselves as ineffective at developing a diverse and inclusive leadership bench. So, what can tech organizations do to ensure that D&I initiatives are successful?
- Diversity and Inclusion need to be embedded across the entire organization and supporting every function, starting with interns and all the way to corporate boards.
- D&I initiatives need to be measured and reassessed frequently. It's not enough to put in place diversity programs and then fail to assess and measur effectiveness. Organizations need yearly or even quarterly check ins on the effectiveness of their D&I programs through surveys, consensus groups and studies of the attrition and hiring numbers.
- Diversity alone isn't enough. Organizational practices and cultural norms need to support inclusion. Organizations often begin by stressing diversity in hiring but place less emphasis on long-term inclusion efforts, which can have detrimental impacts to any D&I strategy. A successful inclusion strategy should be built around regular bias training and awareness programs, workshops and constant reinforcement by leadership.
The process of building software has evolved over the years to build in efficiency, velocity and inclusiveness. The evolution itself has made us realize that segregating various parts of the industry is detrimental to the process and ultimately leads to an inferior product. It’s a simple lesson learned in diversity and inclusion that is key to not only building a better organization but a better world. It's time to lean in and focus on building inclusive organizations where the richness of our diversity is preserved and celebrated.
About the Author
Geetika Tandon is Managing Director with Deloitte consulting LLP with over 20 years of industry experience with technology consulting. She started her career in IBM as a developer working on voice and RFID solutions, moving to middleware implementation and then acquired deep expertise in IT modernization, helping multiple government agencies move to a cloud and DevOps environment.