Is Agile supporting or hindering (economic) sustainability?

Long term economic sustainability

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.


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 toward 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 toward 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?

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 toward, any direction is a good direction. However, Agile indeed means working from a vision and toward it. And you need to retrospect the vision along your journey.

Just for the record, this need for long-term thinking has been well defined for quite some time, as in Agile Chartering, portfolio managing, release planning, and so-called “rolling lookahead plans” (see D. Larsen & A. Nies, Agile Liftoff (2011); J. Rothman, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects (2016); and M. Cohn, Agile Estimating and Planning (2006)).

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:

  • The further out something is, the fewer fine-grained details we provide. For example, we wouldn’t know any particular stories a team would work on in a year; however, we would have an idea of the epics we would like to focus on in the next couple of months, and we would have an idea about the “(strategic) themes” that will be important in a year. Themes provide a much-needed sense of direction.

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.

  • What you learn as you go will influence your long-term perspective. So perhaps some epics will shift due to new insights. Maybe a theme turns out to be not important anymore because of market changes. Or maybe based on the technology that you keep discovering, something further out would be better to do sooner. So, the long(er)-term projections keep changing with the learning (versus in Waterfall where your goal is to “make your original plan work”).

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:

  • You need a sense of direction to make decisions in the here and now on your “next right step.” (ref. Dave Snowden, “Cynefin St David’s 2021”)
  • You have to ensure that retrospectives include also prospectives/futurespectives. This way they don’t only focus on improving efficiency but also continuously check the validity of your long-term direction.
  • Understand that “pivot or persevere” is not only applicable to start-ups. It is also essential in established businesses, maybe just on a more granular level.
  • If you don’t know the way forward, as soon as you discover that the current direction isn’t sustainable, stop it! And instead, fully embrace the “learn & adapt” promise of Agile!

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.

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They may not represent the opinion or policy of Agile Alliance.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Recent Agile Alliance Blog Posts

Post your comments or questions

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now