Agile is in crisis: Here’s how we make it work for our clients

This year, the Agile manifesto turns 20 years old. At just 68 words long, the manifesto offered an alternative framework to common problems experienced in software development.

Now, organizations and teams everywhere base all types of work on Agile methodologies. From startups to large corporations, no one could turn a blind eye to the promises of flexibility, value-driven deliveries, and faster time to market.

But here’s the problem. Agile is in a crisis. It seldom produces the results it once promised. So, let’s take a look at how you overcome this barrier.

The promises of Agile aren’t being realized

The principles of Agile are meant to enable faster, better, and cheaper development and increased business value.

However, these promises aren’t being realized. An oft-cited reason for Agile’s failure is its deployment in the wrong environments—especially large corporations with extensive, entrenched hierarchies, legacy infrastructure, and inflexible cultures that come up against the methodology. So, the argument becomes, “become an Agile organization to enjoy the benefits of Agile”.

In reality, large corporations cannot be changed on such a scale. And so, the question becomes, “Can the Agile methodology still benefit large corporations? If so, how?”.

How we apply the Agile manifesto to real-life scenarios

Being agile implies adapting to the situation, including environments like the ones of large enterprises. Applying an Agile methodology by the book quickly deteriorates to “yet another process” without improving how projects are done substantially. Therefore, we focus on the four principles at the heart of the Agile manifesto:

Based on these, our proven Agile approach to delivering caters for the realities of large enterprises:

Working software over comprehensive documentation

Not always having a working state of your software was an issue when Agile was first established. However, if you don’t have this in place today, e.g. having set up continuous integration systems and dev ops, it’s crucial that you invest to get to this point, which should be standard by now.

However, what’s also needed to truly benefit from Agile is continuous documentation.

Documentation has traditionally been looked down upon because oftentimes it was not up to date with the code or—even worse— was based on a long specification phase before any actual implementation began. By this point, the documentation would already be very outdated, useless, and even an impediment, since someone could still enforce the outdated information.

On the contrary, Agile documentation is continuously developed slightly ahead of development, giving us the advantages listed below:

Customer collaboration over contract negotiation

Customer collaboration is not trivial in the world we live in. We work with clients who usually have other suppliers in their projects, too. More often than not, we have a huge mix of organizations and individuals with different interests and different agendas.

In this situation, trust is paramount to making Agile work. In fact, everything that centers around collaboration is down to trust. When people trust you, they want you to find a solution rather than needing to refer to a contract to clarify points—in fact, if contracts are quoted, it could be argued that all parties have lost already.

Here’s how to build that trust:

Individuals and interactions above processes and tools

Apparently, everybody hates processes. They’re perceived to be constrictive and slow down interactions. But, there are many different processes, and when they work, no one bats an eyelid. They facilitate great work and serve a purpose.

Let’s consider the bigger picture. Processes are in place to achieve a certain goal. Usually, that goal is to be reproducible and to increase efficiency. There are several benefits of processes:

Establishing processes that are truly helpful is essential, as well as rethinking the restrictive ones. Can you improve them? If not, how can you manage them efficiently?

And remember, even if there are processes in place, you must always ensure that human interaction takes place, too.

Responding to change over following a plan

Contrary to popular belief, working without a plan is not agile—it’s chaotic. Constantly changing directions does not move projects forward, but keeps them in a state of disarray.

Agile planning is actually more work compared to traditional planning, because one has to cater for changes and constantly adapt, which is not feasible with detailed planning down to the last dependency.

Instead, we recommend agile planning:

One crucial topic involved in planning is estimates. How can you schedule anything if you don’t know how much time and money is needed to deliver it? However, estimates are always wrong. One mitigation to this was the invention of story points. As they do not translate directly to time or money, they don’t create expectations that might not be met. But in the end, sooner or later everybody just assumes one story point to be a certain number of days.

Some claim that given this situation, estimating would be a pointless exercise, as it is wrong anyways. But not estimating is not a solution. When you drive through fog, you don’t put a blindfold on just because it’s hard to see in the first place.

Instead, be aware that estimates won’t be accurate and adapt accordingly. Again, it doesn’t help to just add a 20% buffer to everything. This will be used up, since any overestimate is used immediately. People always find a way to use up the entire budget they are given.

Complement the Agile plan described above with estimates:

Based on the experience you gather over the course of the project, your Agile plan and estimation will improve continuously.

An approach to successful Agile delivery

Following the approach outlined above, you will have multiple mini developments, meaning an estimation and planning per module, spec per functionality, and you can develop accordingly. Although this sounds like a waterfall model to some degree, the issue with waterfall is the disconnect between the original planning, definition, and final delivery—which can sometimes take years.

Instead, consider very short waterfalls that ensure the robust development of individual features that also fit into an overarching plan that continuously adapts to new developments.

This approach is not new or fancy. It has been around for quite some time and sometimes is called iterative or incremental development. It is time to remember it, as it perfectly combines the best of traditional and Agile methodologies and allows to deliver outstanding results.

Working with Netcentric, you’ll see that our competency and excellence lead us to excel. Agility is built into our DNA, as well as exceptional delivery.

We don’t take success for granted. This enables us to be the best digital partner to our clients. We expertly steer them in the best direction and deliver them exceptional experiences, time and time again.