From Agile to Fragile

I’ve been considering giving my take on “Agile Methodology” for a long time. It’s a topic that can spark strong opinions and might even ruffle some feathers among those in the IT industry who adhere strictly to “Agile Frameworks” as infallible formulas to make development teams deliver software better and faster.

For years, the software industry has been inundated with talks and coaching selling magic recipes. I’m usually skeptical of anything that turns into a buzzword, especially when it falls into the hands of “business people”. It’s amazing how quickly a brilliant idea can go from a cultural shift in software development to being slapped onto overpriced consulting slides and certification mills.

Knowledge is the only way to avoid being fooled by false promises. In this post, I’ll try to set the base with historical context and give my take. After nearly 20 years of transitioning through various management styles, methodologies and technologies, I’ve earned the right to share my thoughts and vent a little.

When the waterfalls

Let’s delve into the historical context of Agile Manifesto. In 2001, 17 Knights of the Round Table, armed with their sharpened laptops, gathered at The Lodge at Snowbird ski resort in Utah, USA, to pen the Holy Scriptures, aka “The Agile Manifesto”. This pivotal event was a guiding light that steered software development toward the promised land.

But jokes aside, the creation of the Agile Manifesto was disruptive at the time because it addressed decades of frustration with traditional software development methods in a unified way. Back in the day, companies would sink vast amounts of money and time into a complex, lengthy process to analyze and gather all client requirements upfront, plan out every phase, and then march forward step by step, only to find out too late that many or most of the requirements or technical aspects hadn’t been properly considered. Yes, human beings are terrible at predicting the future, although some claim the opposite.

This approach, popularly known as Waterfall, treated software development like an assembly line - a model that works great for manufacturing cars, but fails when applied to software (I swear it’s not a reference to Toyota’s Kanban), built from unpredictable code and sometimes for temperamental clients. After all, software isn’t hardware, and predicting its long-term outcome with accuracy is like predicting the weather a year upfront.

Let’s check the manifesto from the source: agilemanifesto.org

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

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

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

By looking at the names of who signed the manifesto, you’ll quickly identify some true rock stars of the development industry that contributed with papers and classic books about programming, clean code, refactoring, testing, and so on. Also, some of them formulated what we know as “Agile Frameworks” such as Scrum (Ken Schwaber and Jeff Sutherland) and XP (Kent Beck) and Crystal (Alistair Cockburn).

While these frameworks laid the foundation for what we now know as Agile, they weren’t widely adopted or labeled as such. What truly made the Agile Manifesto disruptive was how it brought these ideas together, clearly and cohesively, sparking widespread traction and transforming the industry through a cultural shift. The manifesto was their direct response to the frustrations faced by developers and, project managers and obviously, clients.

Agile Frameworks

For historical context, let’s check a chronological rundown of the most popular ones:

Kanban: Founded in the 1940s by Toyota Production System, but adapted and formalized for software development in the early 2000s, it’s a visual workflow management method that engages teams by helping them visualize their work, limit work in progress (WIP), and optimize flow. Unlike Scrum, Kanban does not prescribe fixed iterations but focuses on continuous delivery.
Proposed applicability: Teams looking for a flexible, flow-based approach to work. Common in operations, support teams, and maintenance work.
Lean: Founded in the late 1940s, also by Toyota Production System, although the term “Lean” was coined in 1990, it focuses on delivering value by eliminating waste, improving processes, and optimizing resources. It originated in manufacturing but has been adapted to software development and other industries.
Proposed applicability: Organizations aiming to maximize efficiency by reducing waste and focusing on value delivery.
Scrum: Founded in the early 1990s, and formalized by Ken Schwaber and Jeff Sutherland in 1995, it’s most popular, particularly in software development. It is characterized by time-boxed iterations called sprints, lasting typically 1-4 weeks, with clearly defined roles (Scrum Master, Product Owner, Development Team), ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment).
Proposed applicability: Teams that need a structured yet flexible approach to product development.
Extreme Programming (XP): Founded in 1996 by Kent Beck, Extreme Programming emphasizes technical excellence and continuous improvement. It includes practices such as pair programming, test-driven development (TDD), continuous integration, and frequent releases.
Proposed applicability: Teams in environments where requirements change rapidly and high-quality code is critical. It is common in software development teams that prioritize technical practices and code quality.
Crystal: Founded by Alistair Cockburn in the late 1990s / early 2000s, it is a family of methodologies emphasizing people, interactions and the uniqueness of each project. Crystal was part of the broader set of ideas that contributed to the Agile movement and the eventual drafting of the Agile Manifesto.
Proposed applicability: Teams that need a highly adaptable approach tailored to their specific project needs.

Some frameworks were also created post-manifesto, supposed to address new challenges:

Disciplined Agile (DA): Founded by Scott Ambler and Mark Lines in 2009, provides a toolkit for tailoring Agile practices to specific organizational contexts.
Proposed applicability: Organizations with complex, hybrid environments that combine multiple Agile and traditional methods.
Scaled Agile Framework (SAFe): Founded in 2011 by Dean Leffingwell, it was designed to scale Agile practices across large enterprises. It integrates Scrum, Kanban, and Lean principles, including additional roles, responsibilities, and ceremonies to manage large-scale projects.
Proposed applicability: Large organizations looking to scale Agile across multiple teams and departments.

With this foundation in place, let’s explore what has gone wrong with Agile practices today.

What’s broken with Agile?

Scrutinizing Scrum

For my criticism, I’ll primarily refer to Scrum, which is statistically the most popular framework and the one I’ve had the most practical experience with. Scrum is famous to the point of being wrongly referred to as a synonym of Agile itself. Hence, all the criticism towards the current state of Scrum indirectly targets Agile, and I notice a growing anti-agile movement because of that.

1 - Additions with management appeal

Scrum was initially conceived as a lightweight guideline focused on delivering increments of potentially shippable products in short iterations (Sprints). It was initially supported by a few ceremonies, such as sprint planning, daily Scrum (or stand-ups), and sprint review. Over time, it changed. I mean, a lot. More ceremonies were added, intra (Refinement or Grooming) and after sprint (Retrospective).

Other additions associated with Scrum, though not mandatory according to the official Scrum Guide, like Story Points, were set as the method for estimating the effort in relative terms, required to complete User stories (a simple way to capture requirements from the user’s perspective), also added more lately. Moreover, these additions to Scrum have shifted its focus away from the original simplicity and autonomy that empowered development teams, turning it into a process more suited to pleasing managers with a false sense of control.

One in particular, the Burndown Chart (I like to call it Burnout Chart), although not mentioned in the original formulation of Scrum, is commonly used by Scrum practitioners to track progress during sprints. I’m still waiting to see a high-performing development team wanting to use it voluntarily. Instead, management often uses it to emphasize the velocity of the work completed, no matter what value the work adds to the customer. The result is always high pressure, poorly designed products, and low morale, especially when interpreting questionable data as a metric of progress, ignoring context, and valuing outputs over outcomes.

I’ve witnessed it several times during my career, and companies pushing developers to “play the game” results in teams manipulating numbers to make it look like the velocity of their work was either consistent or improving every iteration. Several other popular tools (e.g., Jira, Trello) back up this practice by providing all sorts of statuses and visual representations that overemphasize “velocity”. Associating these tools with Agile hurts and leads the industry to a very bad course.

Speaking of User Stories, as a developer, I’ve always felt non-practical having to commit to something described as “as a customer, I want to do this” instead of having more specific requirements. After all, management and customers always expect the development team to deliver something on time within a limited budget, and for estimation, well, with experience you have a gut feeling about how long something takes to be built, but this totally depends on the developer experience the company provides (I wrote about it in this post) and the developer’s seniority, why I find inaccurate putting mixed skilled developers to vote the effort for building something in a gamification fashion style like Planning Poker and fibonacci sequence.

It’s not uncommon that inexperient Scrum Masters make a wrong correlation between story points and time (days), and that alone constantly inhibits experienced developers from sharpening the axe for longer than inexperienced ones, for then cutting the tree once. Who wants to tell the truth when the environment rewards velocity speed over quality?

Note: Interestingly, you won’t find a formal changelog with a timeline with these additions, so it can continue changing its course without notice for new scrum practitioners with no historical context.

2 - Meetings, meetings, and more meetings

The combination of all these ceremonies will cost countless hours in meetings, most of which are driven by non-technical staff (Managers, Product Owners). This can lead to very unproductive and unmotivated teams. Software development requires focus, study, and discipline, and having the mental flow constantly broken drives the team to feel that a two-week sprint is not enough to develop anything with quality or value.

3 - “Scrum without XP doesn’t work”

I strongly believe in this statement. It’s often attributed to Ron Jeffries, one of the co-creators of Extreme Programming (XP), but it’s shared by other thought leaders who stress the importance of combining Scrum with XP practices to achieve technical excellence. Software is not an end on its own but a means to an end. It’s a way to do something someone needs digitally. Like any technological or engineering product, how can one build software without best technical practices at the core? The technical practices proposed by XP (test-driven development, continuous delivery, continuous integration (CD/CI), refactoring, and technical collaboration through pair programming) are proven tools that must be part of the daily basis of any serious team nowadays.

Martin Fowler, one of the manifesto’s signatories, also wrote an article called Flaccid Scrum, in 2009, denouncing the lack of efforts from the scrum community in ensuring the importance of strong technical practices. Unfortunatelly, as I write this post, it’s still happening, if not getting worse.

Whether Scrum is a good fit for your team or not, it must act as a lightweight wrapper for XP practices if you want your development team to thrive in delivering sustainable increments to the customer. Otherwise, as I intended with the title of this post, it becomes a very fragile process, targeting management only and nothing else.

Certifications and Scaling Agile

Certification Mills

The Scrum Alliance has been constantly criticized for leading to the proliferation of certification programs, some of which are seen as “certification mills”. There are certifications (trademarks) for different target audiences, like CSM - Certified ScrumMaster®, CSPO - Certified Scrum Product Owner®, and CSD - Certified Scrum Developer®. It’s a very profitable market, especially when plenty of organizations use these certifications as hiring criteria rather than practical experience, technical or managerial.

I don’t want to be demeaning to any certification here, and I understand that everyone needs to make a living. Like any other certification, it only proves the certified passed an exam with multiple-choice questions about something, and nothing more than that.

Maybe the very existence of Scrum Certifications is a sign that the process has become so nonintuitive that reading a small guide is not enough. This becomes harmful when certified professionals apply whatever the latest iteration of Scrum preaches as an unthinking and immutable recipe. Being agile also means being able to change a process that doesn’t fit well. Remember: “Individuals and interactions over processes and tools”.

What’s actually being Agile?

Though the word Agile is an adjective and its meaning varies depending on the context it’s applied (physical or mental), we can assume that’s the ability to move quickly. And you can only move quickly if you’re flexible to change. Oh, and it was also and arguably used to label the “Agile Methodology” for software development.

I love when Uncle Bob (Robert C. Martin), one of the manifesto’s signatories, hits the nail in a short video, “Taking it Back to the Basics”, with saying:

A really simple idea, mostly based on the ideas in extreme programming and scrum and a little bit of FDD (feature-Driven Development). Agile, a very effective small technique for relatively small teams, to do relatively small things. That’s what agile was, That’s what agile always will be.

Scaling it up

Then, he ends it with:

What about big teams and big things? Well, that’s not the problem Agile will set out to solve; although I think it is a solved problem, I just don’t think it’s an Agile problem

It clearly synthesizes what’s wrong in most of the software industry right now. Bloating projects with rigid processes and people results in the opposite of agility, especially when neglecting technical excellence and all the other problems I mentioned previously. The market adapts quickly, and for every new problem, there are snake oil salesmen promising solutions to solve them and make companies feel more SAFe.

As a developer, I’m used to dividing big problems into smaller pieces to conquer, and with Agile, it wouldn’t be different. I like to take, for example, the tailored model used by Spotify, the largest and most popular audio streaming subscription service in the world, to remain flexible, though still a large company.

If your organization can’t customize the process to fit its needs, it can’t be Agile at all. By not being Agile, it can’t respond quickly to changes in the wind, and being beaten by the competition is just a matter of time.

I can’t forget to recommend Uncle Bob’s book titled Clean Agile: Back to Basics. The title is self-explanatory.

Final thoughts

This post was a call from a software engineer and technical lead who loves to craft great products and work with great teams but feels displeased with the industry’s course and how it subverted Agile. Agile is the best way to develop software, one of the most interactive and interesting activities humankind could create.

High-performing teams work towards a common goal, rely on trust and collaboration, invest efforts in genuinely understanding customers’ needs, and implement it through technical expertise supported by good engineering practices.

There are plenty of tools emerging every day to ease software development and automation that solve problems at a global scale. Now, more than ever, it’s time to reflect on what makes “Agile” agile and ensure that teams remain adaptable, collaborative, and focused on adding value to customers rather than overcomplicating what is already challenging. Happy coding!