Back to Posts

When To Use Agile And Why It Fails

Posted in pm

Before the prevalence of web products, product creators meticulously spent their time crafting the perfect product. This was out of the permanency of products. The non-malleability of a tangible product after launch forced the people in charge to attempt to design a flawless creation.

In the past fifteen years, malleability is required with the prominence of web-based products. With this, we can constantly iterate and improve on our initial releases to meet the needs of an evolving user.

Over the past decade, agile methodologies and shipping quickly has become table stakes. The reality of how it’s implemented, however, is far from optimal.

The cool kids are doing it

In 2001, a group of developers released the Agile Manifesto outlining the twelve covenants defining agile. Since then, every tech company under the sun has attempted to run a lean, mean, agile machine yet few run it with grace and consistency.

agile versus waterfall

The popularity of agile methodologies and the competitive tech market created an imbalance between competency and expectations. As the waterfall methodology became an unfavourable product management process, larger corporations turned towards agile. The main problem in this was the lack of understanding of why teams use agile in the first place.

Because of this, the reality is many developers hate agile. It’s not the process so much the poor management and lack of fundamentals.

Staying agile

So, why do we use agile? There are many reasons outlined in detail online, however I’ll focus on three fundamental to shipping early and often:

  • Focus
  • Risk mitigation
  • Isolating successes and failures

One benefit of agile is it provides focus to cross-functional teams, with short-term goals helping guide the team. Sprints clearly define what needs to be done tied with a specific metric defining success. Compared to waterfall where countless features needs to be pushed for a final release date, agile provides focus for developers, designers, product managers, and QA to build out a successful component.

Risk mitigation is another benefit of agile. The longer time spent between shipping features, the larger the risk for failure. This happens in a multitude of ways, however the main one being lack of feedback. Iterating on learnings is fundamental in successfully releasing an agile product.

Focusing on iteration, by shipping early and often, we can isolate successes and failures in features.

This provides basis to continually test, amplify, or soften certain areas. Over the long-run, this saves us time and resources in pinpointing problem areas within a traditionally released product.

When agile fails

Generally, we can categorize agile failures into three buckets:

  • Lack of understanding
  • Lack of trust
  • Lack of flexibility

The main reason why agile fails is that many product managers or scrum masters are highly inexperienced working with agile. A scrum master with two days of training or management adhering to legacy structures will damage the foundation of an agile team. An over reliance on micro-managing developers or designers, and a discombobulated feedback cycle on the user side are symptomatic of low understanding.

Lack of trust is something else detracting from the value of agile. Often times product managers are draconian in their approach and are unrelenting in their opinions leading to developers who feel like code monkeys with high pressured deadlines and scrutiny to execute quickly.

This creates discord and discontent between teams as projects move forward.

Lastly, lack of flexibility in using agile. The whole point of agile is to iterate quickly, and be malleable as new information enters the system. Processes may be optimal or sub-optimal given a specific project and it’s important to know when to be flexible in the process.

The first step in flexibility, however, is understanding the fundamentals, and why each step is being done. From here, we can determine where changes needs to be made to compliment different teams and goals.

A final thought

What prompted me to write this article was a comment on a blog post I read online about a developer frustrated with pushing shitty code that he had to spend hours working tirelessly to fix after their minimum viable product (MVP) launched.

what is a minimum viable product mvp

It was the cyclical nature of push, fix, push, fix, push, fix that bothered him the most. Although technical debt is a tradeoff for speed, it isn’t the only thing that should be optimized for. Shipping quality products is a balance between all things.

Read Next

Open Source vs. Proprietary Software in Practice