Agility helps projects respond to change, learn faster, and continuously adapt to emerging needs. At the same time, sustainability asks us to look beyond immediate value and consider the longer-term consequences of today's decisions.
But what happens when these two perspectives pull in different directions?
Could frequent adaptation, continuous reprioritization, or a strong focus on immediate value unintentionally create rework, consume more resources, or shift attention away from longer-term impacts?
Perhaps the challenge is no longer simply how agile a project can become, but how much agility is appropriate for the value we want to sustain.
Can a project become too agile to be sustainable?
And if so, where should we draw the line between responsiveness today and responsibility for tomorrow?
Saving Changes...
Sort By:
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
A very interesting tension, Farshid. I would perhaps question whether a project can become too agile, or whether adaptation can become too frequent, too local, or insufficiently governed to remain valuable.
Agility is not simply the frequency of change. A project that continuously reprioritizes without sufficiently considering the consequences may be highly changeable without being meaningfully adaptive. Conversely, frequent adaptation may reduce waste and protect longer-term value when new evidence shows that continuing on the existing path would be more damaging.
Sustainability therefore may not need to constrain agility so much as broaden the criteria by which adaptation is judged. The question becomes not only whether a change creates immediate value, but what resources it consumes, what consequences it creates, for whom, and over what time horizon.
This also matters beyond the project itself. An adaptation that improves local delivery may create technical debt, operational burden or wider impacts elsewhere in the system.
So perhaps the line is not between responsiveness today and responsibility for tomorrow. The challenge is to make responsiveness itself responsible, by grounding adaptation in evidence, proportionality and an assessment of both immediate and longer-term consequences.
...
1 reply by farshid adavi
Aug 13, 2026 11:32 AM
farshid adavi
...
Thank you, Luis. I really appreciate this distinction between frequent change and meaningful adaptability. Your point about broadening the criteria for adaptation is especially valuable. Perhaps sustainability adds a longer time horizon to Agile decision-making: not limiting responsiveness, but asking whether today’s adaptation preserves value and options for tomorrow. A very useful perspective—thank you for adding it.
I'd like to look at this through a different lens - how does a project become "too" agile? While agile frameworks and methodologies do allow for discovery and emphasize early delivery of value, I think what you're describing may be a reflection of people optimizing behaviors associated with agile, but I'd like to suggest that it's not really an agile problem, at least not in all cases.
Organizations regularly trade future efficiency, quality, resilience, and cost for present speed or value, regardless of whether the work is being accomplished through agile projects, waterfall projects, or operations. I've been on projects intended to resolve a specific problem that were delayed in favor of a quick fix only to have to come back six months to a year later and run the project. The developers were frustrated, but closer examination of the business drivers showed that it made sense at the time.
It doesn't always make sense. I worked at a company that always optimized for and rewarded speed. Sometimes it worked. Sometimes things failed shortly after all involved were rewarded for going faster. This mindset can present itself in agile projects, but it's often an organizational level problem presenting itself at the project level. I don't think you can solve this at the project level, unless it only exists at the project level.
Instead of asking whether a project can be too agile to be sustainable, I would ask "When does optimizing for speed begin to undermine the organization's capacity to create value over the long term?" The symptoms you describe are real. The erosion of delivery capacity has been shown to be an outcome of short-term optimization. In the early stages, if it's noticed, it often gets ignored. It's the boiling frog story - toss them into boiling water and they jump out right away. Heat the water slowly and they cook. While they're cooking, someone is warning about technical debt and being treated like chicken little. The end state is that the organization optimized for speed so consistently that it made itself slow. The organization hasn't become too responsive. It has repeatedly sacrificed future responsiveness to obtain present responsiveness.
Ultimately, yes, sustainability has been sacrificed, and that needs to be addressed. The reason behind my reframing the question is that if you only focus at the agile project level, you won't see the larger problem, if there is one, and will be less likely to be able to resolve it.
...
1 reply by farshid adavi
Aug 13, 2026 11:34 AM
farshid adavi
...
Thank you, Aaron. I really appreciate this broader organizational perspective. Your point about local optimization is particularly important: what appears efficient at the project level may actually transfer costs or constraints elsewhere in the organization or into the future. Perhaps this is where sustainability can help connect project-level responsiveness with longer-term organizational value. Thank you for expanding the discussion in this direction.
A very interesting tension, Farshid. I would perhaps question whether a project can become too agile, or whether adaptation can become too frequent, too local, or insufficiently governed to remain valuable.
Agility is not simply the frequency of change. A project that continuously reprioritizes without sufficiently considering the consequences may be highly changeable without being meaningfully adaptive. Conversely, frequent adaptation may reduce waste and protect longer-term value when new evidence shows that continuing on the existing path would be more damaging.
Sustainability therefore may not need to constrain agility so much as broaden the criteria by which adaptation is judged. The question becomes not only whether a change creates immediate value, but what resources it consumes, what consequences it creates, for whom, and over what time horizon.
This also matters beyond the project itself. An adaptation that improves local delivery may create technical debt, operational burden or wider impacts elsewhere in the system.
So perhaps the line is not between responsiveness today and responsibility for tomorrow. The challenge is to make responsiveness itself responsible, by grounding adaptation in evidence, proportionality and an assessment of both immediate and longer-term consequences.
Thank you, Luis. I really appreciate this distinction between frequent change and meaningful adaptability. Your point about broadening the criteria for adaptation is especially valuable. Perhaps sustainability adds a longer time horizon to Agile decision-making: not limiting responsiveness, but asking whether today’s adaptation preserves value and options for tomorrow. A very useful perspective—thank you for adding it. Saving Changes...
I'd like to look at this through a different lens - how does a project become "too" agile? While agile frameworks and methodologies do allow for discovery and emphasize early delivery of value, I think what you're describing may be a reflection of people optimizing behaviors associated with agile, but I'd like to suggest that it's not really an agile problem, at least not in all cases.
Organizations regularly trade future efficiency, quality, resilience, and cost for present speed or value, regardless of whether the work is being accomplished through agile projects, waterfall projects, or operations. I've been on projects intended to resolve a specific problem that were delayed in favor of a quick fix only to have to come back six months to a year later and run the project. The developers were frustrated, but closer examination of the business drivers showed that it made sense at the time.
It doesn't always make sense. I worked at a company that always optimized for and rewarded speed. Sometimes it worked. Sometimes things failed shortly after all involved were rewarded for going faster. This mindset can present itself in agile projects, but it's often an organizational level problem presenting itself at the project level. I don't think you can solve this at the project level, unless it only exists at the project level.
Instead of asking whether a project can be too agile to be sustainable, I would ask "When does optimizing for speed begin to undermine the organization's capacity to create value over the long term?" The symptoms you describe are real. The erosion of delivery capacity has been shown to be an outcome of short-term optimization. In the early stages, if it's noticed, it often gets ignored. It's the boiling frog story - toss them into boiling water and they jump out right away. Heat the water slowly and they cook. While they're cooking, someone is warning about technical debt and being treated like chicken little. The end state is that the organization optimized for speed so consistently that it made itself slow. The organization hasn't become too responsive. It has repeatedly sacrificed future responsiveness to obtain present responsiveness.
Ultimately, yes, sustainability has been sacrificed, and that needs to be addressed. The reason behind my reframing the question is that if you only focus at the agile project level, you won't see the larger problem, if there is one, and will be less likely to be able to resolve it.
Thank you, Aaron. I really appreciate this broader organizational perspective. Your point about local optimization is particularly important: what appears efficient at the project level may actually transfer costs or constraints elsewhere in the organization or into the future. Perhaps this is where sustainability can help connect project-level responsiveness with longer-term organizational value. Thank you for expanding the discussion in this direction. Saving Changes...
Community Champion
