Category: Process

When Agility Breeds Entropy: The Hidden Cost of the AGILE Process

~ cjois

Agile has transformed software development. It replaced rigid waterfall structures with flexible sprints, rapid feedback, and constant iteration. Teams move faster, deliver sooner, and adapt to change with ease. But beneath this celebrated adaptability lies a subtle and growing problem – entropy. The very qualities that make Agile powerful can also accelerate the disorder of software code.

In an Agile environment, developers are encouraged to prioritize delivering working software over exhaustive documentation and long-term architectural planning. This is great for short-term progress – but over multiple sprints, it often leads to shortcuts, fragmented designs, and inconsistent coding patterns. Each sprint adds a new layer of functionality, sometimes built on incomplete refactors or temporary fixes. Because the focus is on “delivering value now,” deeper architectural integrity can be deferred indefinitely. Over time, the codebase starts to resemble a geological formation – with layers of old design decisions, patched logic, and duplicated functionality. The result? Increased entropy: a system that works today but resists adaptation tomorrow.

Agile also introduces entropy through team dynamics. As teams rotate, priorities shift, and user stories evolve, institutional memory weakens. The rationale for design decisions fades, documentation lags behind, and technical debt accumulates quietly sprint after sprint. Ironically, the very agility that enables rapid evolution also erodes long-term stability. The cumulative effect is a codebase that becomes progressively harder to maintain, extend, or even understand.

To counter this entropy, Agile teams must embrace sustainable agility – balancing iteration speed with architectural stewardship. This means treating refactoring and technical debt reduction as core deliverables, not optional chores. It means embedding architecture reviews, code quality metrics, and documentation updates into the sprint rhythm. Agile, at its best, is not chaos – it’s disciplined flexibility. But without mindful engineering, it can devolve into a cycle of entropy masked by velocity.

In essence, Agile doesn’t create entropy — people do, when they mistake iteration for improvisation. The key is to use Agile not just to build fast, but to build well, ensuring that with each sprint, the system grows in both functionality and structural coherence.

CP Jois

Why AGILE fails to be agile?

~ cjois

The term ‘agile’ is much used today in many different contexts – so used that its bordering on overuse or misuse. The software industry is perhaps the one that uses it the most – so much so that it coined an entirely new process model known as AGILE hoping to jumpstart a new revolution in software engineering. While there has been a lot of talk around it, this revolution has barely provided the uptick in software project success it was meant to.

Why?

There are many reason for this. One of the reasons is that while labels have changed, basic behavioral aspects have hardly changed. Software engineers don’t do much different today, software managers hardly understand the nuances between process models/methodologies. Even more importantly, customers cant seem to change their modalities as participants in the process. Transformative change requires change at all levels, in every stakeholder role. For example, AGILE requires that customers/clients become participants in the daily activities of an AGILE effort. This calls for deep commitment and necessary time adjustments. While easy to state, this isn easy to achieve. Funding models have to change. The term ‘project’ and AGILE don’t go together. AGILE efforts are on going efforts, burning down a backlog of requirements. Projects have fixed scope, time and budget – the triad. AGILE efforts – as per the very AGILE manifesto – are meant to take on change late in the process. The typical ‘Project’ attempts to control scope and rigidly guard its execution. Looked at from a high level, these are counter to each other.

The majority of software engineers hardly understand these nuances. The typical software manager struggled to deal with traditional project execution, let alone have to deal with brand new terminology and safeguards. The very definition of a requirements changed with time. From writing 100s of pages of software requirements, the ‘Iterative’ process cycle asks for use-cases in an Actor-Ability syntax. On the other hand, AGILE demands User Stories. Speak to the average software developer and it becomes apparent that the nuances are barely even understood. The situation is analogous to the time when object oriented programming models came along but it took a long time before the industry truly wrote any real object oriented code. Even today, it isn’t unusual to see engineers writing long segments of procedural code while using advanced object oriented programming languages. Software is still a nascent industry. Success is still a matter of striving till it gets done. The ‘soft’ nature of the outcome makes it very hard to measure. Traditional practices have yet to stabilize. Complexity has been on the rise. In fact inter-operable systems and cooperating systems have become the norm.

One of the fundamental goals of AGILE was to get more features out, quicker. Getting a quick Sprint 0 done has become an obsession – most AGILE projects don’t care to build solid foundations. This concept of a MVP may be very lucrative however when observed closely, most MVP start off wanting to be something and end up being barely one-tenth of that vision. I have performed many due diligence exercises and one observation is common – most AGILE sprints are more about cleaning up the mess left behind by the previous sprint and less about feature roll outs. Hardly are there teams that truly measure that basic goal of “getting more features out, quicker”

For AGILE to truly delivery on its promise, core behavior must change. Until then, it shall remain a fancy label. Core behavior change begins by educating teams (software engineers and customer) to understand the basic tenets of AGILE – starting with the manifesto, the process itself, and the definition of an outcome in AGILE.

Until next time…

CPJ