Is Agile supporting or hindering sustainability for the Business Transformations?
I came across this beautiful article-Is Agile supporting or hindering sustainability for the Business Transformations?
#AgileTransformations#long-termThinking#AgileMindset
👉 We have seen Agile transformations being disrupted by the false belief that Agile doesn’t support long-term or upfront thinking. Often the belief is that long-term/upfront thinking will be a waste of time because things will change anyway. However, the resulting bias towards short-term thinking doesn’t only disrupt Agile transformations, it also hinders implementing (business and environmental) sustainability.
Let’s take a look at Tesla, for example. Tesla is seen and promoted to be a great example of Agile ways of working, using end-to-end thinking across product creation, production, deployment, and support. They have a strong bias for action and a can-do, “let’s try” attitude that focuses on solutions rather than problems. Due to the fast progress of Tesla in e-mobility, now the general public thinks battery-powered vehicles are the only way out of fossil fuel-powered mobility. The emerging social pressure has driven the whole industry to concentrate on this one technology only.
There are still many unresolved issues in electric mobility. A sustainable solution for handling batteries at the end of their life, an aspect known as battery lifecycle management, is yet to be found. Furthermore, the impact of mining Lithium and other rare materials on both humans and the environment is not clear.
The initial impulse to push for Battery Electric Vehicles (BEV) was very much needed to shake up the established car industry, and while that impulse was good at first, after learning that also BEVs have sustainability issues, we now need a balancing countermovement to fundamentally think it through end-to-end: we need to respond to what we are learning! And as Tesla is working in an Agile way, shouldn’t retrospectives have captured this learning?
👉 Efficiency over effectiveness
Looking at how retrospectives are used in established companies, we can see that they focus mainly on removing obstacles to delivering quickly in order to get a fast ROI (Return on Investment). In other words, retrospectives are used for becoming more efficient (“achieving maximum productivity with minimum wasted effort”). In this environment, retrospectives tend to ignore rethinking the general purpose of the development or whether the overall direction should be changed. It seems Agile is being used to make exploitation more efficient.
And, indeed, we observe companies embarking on Agile transformations with the main objective of becoming more efficient in exploitation and improving long-term economic success. However, Agile is also meant for course corrections or being able to cancel an endeavor before all money is sunk, focusing not simply on efficiency but effectiveness, i.e., not simply maximizing productivity but “doing the right thing.”
Let’s look, for example, at an organization that runs Project A and Project B. Both have their funding. Over time, it turns out that Project B doesn’t make sense. But the manager of Project B knows if they terminate the project, the capabilities of the team will be questioned. So, the project is continued. Yet from a business Agility perspective, the better solution would be to terminate Project B and move the team and the funding to Project A.
👉 The real power of retrospectives
Retrospectives started as post-mortems: after a failed project people got together and discussed the lessons learned in order to avoid such a failure in the future. This kind of learning is certainly important; however, for the project that just failed, the insights come too late. Therefore, it was suggested to run retrospectives at high frequency during an endeavor, so that the course of the endeavor can be corrected before it is too late. Originally, the idea of such an Agile retrospective (or of an Agile approach overall) was also to learn if it is still valuable to carry on. Yet, this deep question about the general direction is rarely asked today.
Retrospectives as practiced today tend to focus on delivery, speed, time to market, and removing immediate obstacles. In most companies, teams have the mission to deliver, not to discuss strategy. Due to that, a team’s “foresight horizon” is somewhere around three months. And although a team should have the courage to question the endeavor strategically, often they feel they don’t have the mandate, courage, or information to make such a call. To overcome this, retrospectives are also needed on the strategic level to have the opportunity to improve and correct steering even if it means stopping the endeavor altogether. Although stopping an endeavor that is not promising sounds like failure, doing so before too much money is spent is actually a success.
If we would follow the original intent, the retrospectives would also be prospectives or futurespectives, looking at what we learned and the signals we can see that inform us as to whether our direction is still correct or needs to be changed. Looking into questions like “What is our trajectory?” would help us keep our sense of direction updated. We need to look into scenarios and projections, making use of the known-knowns, the known-unknowns, and our feeling about the unknown-unknowns. (As Han Solo likes to say: “I have a very bad feeling about this!”) Similar to our discipline to backward, we should have the same discipline and rigor to look (far) ahead.
So, is it just about bringing back some things that got lost along the way? Is it that simple? Why did the original intention get lost? Is there perhaps an organizational systemic headwind?
👉 Short-term learning informs long-term thinking
One headwind might be coming from the (in)famous mindset shift that may be associated with an Agile transformation. In the initial enthusiasm about the shift from traditional ways of working towards Agile, “the old” is often condemned and must be avoided, while “the new” represents the glorious new future. We have fallen into the mind trap of believing that long-term thinking is old school, i.e., the Waterfall project planning we wanted to get rid of. Yet, might we have gone from one extreme to the other?
Recommended by LinkedIn
This new trend seems to discourage long-term thinking or upfront considerations. If someone proposes such ideas, they are often met with the argument, “But this is not Agile!” These “Agile Police” can be a pretty strong force in many organizations at the start of an Agile transformation when most people feel insecure as to what this new way of working is or is not!
We have experienced this (unfortunately common) misunderstanding that Agile is about short-term thinking and acting only. If this were the case, then there would also be no need for measuring or learning. If you never thought about where you wanted to go long-term, you wouldn’t be able to tell if what you measured and observed really helped or not.
Or in other words, if there’s no vision, no target to work towards, any direction is a good direction. However, Agile indeed means working from a vision and towards it. And you need to retrospect the vision along with your journey.
And so, the story goes: long-term thinking is lost, and with it, a sense of direction. After some time, the organization struggles and we find ourselves in an Agile backlash: “Agile isn’t working! “And then the old practices are re-introduced, yet sometimes in a different disguise. Is there a better way?
👉 Agile long-term thinking
We need long-term thinking, but what is the Agile version of it? There are several differences to linear (Waterfall) long-term thinking. Agile long-term thinking means the following:
Strategic themes are often based on business projections that aim for delivery at a time far into the future. And because the time is far out, there often isn’t anything else known than a (value) slogan. In many cases, based on what we learn, both the theme and the timing of the theme might shift.
If you learn something that will change your long-term projections, a cost is attached to initiating that change. You need to correct the course of your development. You might have already spent time exploring the market, creating a marketing strategy, and understanding (roughly) what the originally planned features are all about. Now you discover that all that time seems wasted. This is psychologically difficult and leads to the “throwing good money after bad money” phenomenon. Yet, if you ignore what you learned, there will also be a cost attached to the change that is not occurring. For example, if you discovered that an epic will shift because a market has changed, but you keep developing that epic as originally planned, it will cost you unnecessary development time, upsetting your clients by offering something nobody wants (anymore), instead of spending time and effort on features people (now) want.
👉 Conclusion
Agile also includes long-term thinking. In order to acknowledge this, keep the following in mind:
Agile supports sustainability if implemented as originally intended: That is, it is not about short-term thinking and learning but rather applying your short-term learning to your long-term thinking. Let your “here and now” inform your long-term sense of direction.
Authors: