This entry was written as part of the Supporting Agile Adoption program, an Agile Alliance initiative dedicated to supporting organizations and their people to become more Agile.
When the Supporting Agile Adoption workgroup met for a workshop in Stockholm in December, we started out by sharing our top insights from the year. This post reflects my 2019 insights.
If we want to support building software solutions to be more effective, humane, and sustainable (see the vision of AgileAlliance) or to help create workplaces that are joyful, prosperous, and sustainable (see the vision of Scrum Alliance), we make several commitments. Some of them are served well, others not so much. The one commitment I think we seldom serve is sustainability.
Along those lines, Larry Fink says in his “famous” letter to the CEOs:
“Society is demanding that companies, both public and private, serve a social purpose. To prosper over time, every company must not only deliver financial performance, but also show how it makes a positive contribution to society. Companies must benefit all of their stakeholders, including shareholders, employees, customers, and the communities in which they operate.”
There are various definitions of sustainability. The general one refers typically to environmental sustainability. However, according to the definition on Wikipedia, there are three dimensions to sustainability: environmental, economic, and social (which also cover ethics). Thus, from an Agile perspective, this means it is not enough to find out what the customer wants and deliver that value. We need to look further and take full responsibility for:
- The social impact of values we’re creating
- The environmental impact of our products
- The economic impact of our efforts
What does this mean and how can this be implemented?
Social Impact
Often we act as if our responsibility ends by delivering the value/service to the customer. Now the product is in the hands of the customer and we’re out – except for maintenance and further development. However, if we take full responsibility for our products, then we need also to be interested in the usage of the product. Here are several examples where people did exactly that:
Chef
When the developers of Chef found out that one of their customers, the Customs and Border Protection or Immigration and Customs Enforcement (ICE) used their software for running detention centers (ensuring deportation) and the family separation policy, they protested against the renewal of Chef’s contracts with ICE. At first, these protests weren’t taken seriously. Only after the system wasn’t usable anymore because one former employee deleted his code on GitHub, Chef decided not to renew the contract. Additionally, they decided to donate money “equivalent to [their] 2019 revenues from these two contracts” to charities that support people impacted by family separation and detention. This former employee explained: “As software engineers, we have to abide by some sort of moral compass, […] When I learned that my code was being used for purposes that I personally perceive as evil, I felt an obligation to prevent that.”
Another example is Google, who announced that it would not seek to renew its contract with the Department of Defense on Project Maven. This project leverages artificial intelligence to support the military by identifying unique targets. The decision came in 2018 after “thousands” of employees protested the contract via an internal letter, some resigned and lots of media outlets reported on the issue. According to Google’s early vision Don’t be evil, the employees stated in the letter: “We cannot outsource the moral responsibility of our technologies to third parties.”
Both examples, and especially the statements of the developers, make clear how our responsibility doesn’t end with the delivery of the product, instead it never ends. Whatever we bring into the world we have to take care of — and of course, we can have different opinions about what kind of usage is appropriate and what not — yet, we always have to reflect and make a conscious decision taking the social (or even societal) impact into account.
Environmental Impact
“It is time for the computing community to face up to computing’s growing environmental impact – and take responsibility for it!” Andrew A. Chien, Editor-in-Chief of the CACM in his editorial.
There is on the one hand all the hardware that gets outdated way too soon and ends as e-waste, as the global e-waste monitor reports:
On the other hand, ICT might exceed 21% of the global energy consumption by 2030 reports Nicola Jones in her Nature article.
Yet, there are also positive developments. For example, as Google reports in its white paper: “In 2017 alone, we purchased more than seven billion kilowatt-hours of electricity […] from solar and wind farms that were built specifically for Google. This enabled us to match 100% of our annual electricity consumption through direct purchases of renewable energy…”
Of course, you can try to push your company also toward that direction as Amazon employees do currently. Yet you might not operate in the cloud so maybe what you want to do is to enhance the definition of done or rather your tests, to review energy consumption of new features and the whole product.
Certainly, software can also contribute to consuming less energy, for example by meeting virtually. However, as Bernard Aebischer and Lorenz M. Hilty found out in their research: “The growing demand for ICT devices and services outpaces the efficiency gains of individual devices.”
Thus if we are not aware of the environmental impact – that is e.g., the energy consumption of our products – and we don’t act accordingly, ICT will use more resources and not fewer.
Economic Impact
Often the economic impact in the context of sustainability is referred to fair labor, fair trade, and the like. However, it also refers to the goal that no company has an economic benefit at the cost of another one. This means, among other things, that our learning should be shared so we can collaboratively learn for the greater good. Collective learning happens only through collaboration. And it is impossible to increase overall learning – that is the world’s learning – if everyone keeps their own learning private. So, no matter whether we refer to technical learnings or learnings regarding organizational design (like the octopus organization) or ownership and sustainability (see above), we can all only get better by sharing what we’ve learned.
One positive example of a company doing that is Munich Re, an international reinsurance company that is providing insurance for insurance companies. Because of their domain, they started to collect and publish research data in the 70’s – also to competitors – about climate change. They’re convinced that only transparency allows them to learn from others and to improve the data. Moreover, making their learning transparent increases the general societal awareness of climate change and their own resilience.
Therefore, collaborating on learning enables us all to get better over time and as a consequence leads to a mutual economic benefit.
Internal focus is great for delivering cool products but in order to aim for the goal of sustainability we have to reach further and think beyond ourselves, our teams, and our companies. We have to think and to care for the community, the society, and the ecosystem we’re living in. And aiming for sustainability is not just trendy or for fun, it’s necessary for the survival of every business in order to find both talent and clients.
Supporting Agile Adoption Workgroup and the Agile Coaching Network
This article is based on the discussions of the Agile Alliance Supporting Agile Adoption Workgroup. I want to thank Hendrik Esser, Ray Arell, Eric Abelen, Bjarte Bogsnes, Jen Coldewy, Marcin Floryan, John Buck, and Elena Vassilieva for their challenging insights. If you would like to hear part of our conversation about organizational design, you are welcome to listen to this special edition of Agile Alliance’s Agile Coaching Network (ACN) podcast:
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
