Skip Main Navigation

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: 

 

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

 

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:

  • Detailing issues within the documentation is much easier than fixing code
  • Team support is in constant flux
  • It acts as a single point of truth 
  • It increases speed and reduces costs

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:

  • If you promise to deliver something, deliver it
  • Be honest about what you cannot deliver before entering a contract
  • Deliver only quality outcomes 
  • When things go wrong, find the best solution 

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: 

  • They enable reproducibility and are highly convenient
  • They allow you to be pragmatic 
  • They allow you to do your job without thinking about it too much

 

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: 

  • First, identify everything that should be in the scope of the project as a big picture. Cluster these into the main building blocks and schedule those within the budget and timeline limitations. Almost no details should be covered by this rough outline.
  • Similar to Agile documentation, continuously plan in the beginning, starting with the first milestones and refining those to a more detailed working-level plan. Usually, this is for the next couple of sprints (if you are using sprints).
  • Accept that “completion” of a milestone does not mean that all functionality is there, but a sufficiently large proportion. A milestone can be considered complete even though there still are future extensions planned. 
  • While you progress throughout the project, plan the next milestones considering your learnings from the past, including issues that became apparent or changes regarding the scope. 

 

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: 

  • Rough estimates (e.g. t-shirt sizes) for the roughly planned parts of the plan. This allows for an initial schedule of milestones.
  • More detailed estimates for modules and functions within that, allowing to have a schedule up to the next milestone.
  • Fine-granular estimates for the next two to three sprints. Use these to measure and report progress.

 

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.


Stefan Franck

Senior Director

One Netcentric’s co-founders, Stefan is an expert in shaping solutions for clients - from requirements analysis to project specification and more. Stefan sees himself as the link between business and technology and, for over ten years now, he has filled various roles as architect, project lead and lead consultant. Stefan's focus is on the Adobe Marketing Cloud and AEM, to which he is strongly connected from his days at Day Software and Adobe. He says that co-founding Netcentric was one of the best choices in his professional life. Never before been able to work with so many brilliant people.

More News