Why is Agile Software Delivery so hard?

by Jeremy Berriault | Dec 4, 2019

Book your free Breakthrough Call to discuss this topic or any issues you are experiencing.

Why Is Agile Still So Tough to Master?

Agile has shaped the landscape of software development—and many other industries—for over two decades. Its benefits are clear: faster delivery, better alignment with customer needs, and more engaged, empowered teams. Yet, despite all the success stories, many organizations still struggle to truly master Agile. So, why does Agile remain so challenging, even after decades of proven results?

Agile: Simple on Paper, Complex in Practice

If you read Jeff Sutherland’s Scrum: The Art of Doing Twice the Work in Half the Time, Agile seems straightforward. The four core values of the Agile Manifesto are:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
These values seem easy to adopt. However, when teams attempt to implement them, the real complexity becomes apparent.

The Mindset Shift: The Real Challenge

The biggest stumbling block is not the method—it’s the mindset. Many organizations treat Agile values as rigid rules, not adaptable guidelines. Early in my career, I saw Agile as chaotic. But looking back, I realize I’d already used Agile principles long before I knew their name.

A Personal Example: Turning Chaos into Collaboration

During one particularly stressful waterfall project, my team was three weeks behind before testing even started. With a fixed deadline and mounting pressure, I introduced daily stand-ups:
  • What did you do yesterday?
  • What are you working on today?
  • What’s blocking you?
This simple change transformed our workflow. We regained control, finished on time, and avoided overtime. Team morale soared, and collaboration became our new regular.

Agile Values in Action: It’s About People, Not Process

Reflecting on that experience, I realize how the Agile Manifesto’s values contributed to our success. We prioritized people and open communication. We embraced flexibility. Agile isn’t about abandoning all structure—it’s about adapting to what works best for your unique team and project.

Why Agile Still Feels Hard for Most Organizations

So, what’s at the root of Agile’s ongoing difficulty? The values themselves are clear and actionable. The real challenge is letting go of old habits, rigid hierarchies, and the illusion of control. Agile demands a genuine mindset shift: one that fosters openness, trust, and a willingness to adapt. It’s not a checklist or a set of rules; it’s a new way of thinking and working.

Common Barriers to Agile Mastery

  • Cultural Resistance: Teams and leaders often cling to old ways of working, fearing loss of control or predictability.
  • Siloed Communication: Departments operate in isolation, making collaboration harder.
  • Misaligned Leadership: Leaders may support Agile in words, but not in actions or resource allocation.
  • Superficial Adoption: Organizations focus on ceremonies and tools rather than the underlying principles.

The Path Forward: Making Agile Work for Your Team

Mastering Agile requires more than process changes or new tools. It means investing in:
  • Continuous learning and feedback
  • Psychological safety and trust
  • Empowering teams to own their work
  • Leadership that models Agile values
When teams embrace these principles, Agile transforms from a buzzword into a powerful engine for growth and innovation.

Ready to Make Agile Work for Your Team?

If you want to move beyond “doing Agile” and truly live Agile values, let’s talk. I help teams embed Agile into their culture—no matter where they’re starting from.
Reach out at jberriault@berriaultandassociates.com and let’s build an Agile approach that delivers real results for your organization.
$

Individuals And Interactions

over processes and tools

  • We interacted daily

  • Worked as a team to meet the goal

  • Helped each other

  • We still followed the process

  • We even used tools

    • The last two, we were more focused on the first three points than the previous two.

    • We used found efficiencies to get the work done as we went along.

$

Working Software

over comprehensive documentation

  • Get the work done
  • Ensure scope met
  • Ensure test results documented
    • Since this was a bank, the test results are an auditable document. So we needed it.

    • What we did was understand the work needed for an audit and ensure we were compliant. We focused on one set of results. So we ensured that the last run of cases was documented and ensured less duplication.

    • The other benefit we found here was saving a lot of storage space.

    $

    Customer Collaboration

    over contract negotiation

    • We worked with the Business Analyst to ensure what we were testing was what they wanted to see.

    • Shared results

    • There were no contracts of negotiations done

    $

    Responding To Change

    over following a plan

    • As with any project in Waterfall, there are change requests. The team adjusted and still met dates

    • Although there was a Test Plan documented (it was Waterfall after all), we never revisited it. We knew it would take too much time to go over it and figure stuff out then get the approvals. We just planned on the spot and went from there.

    So back to the purpose of this post: Why is it so hard to do agile software delivery? If I was able to do it without any training, why can't some teams get it straight when there is so much documentation out there to help?

    I see it as a couple of things: Taking things too literally and organizations not accepting to be utterly agile in the work they do.

    Taking things too literal is an easy discussion to have. People take a look at the Manifesto and treat it as gospel. Hence where the cowboy comment from earlier came. I have seen teams that treat Agile as a free for all and that they can do whatever they want. When in actuality, Agile needs discipline.

    Yes, teams will have to act fast on stuff that may come in from Business, Clients or senior executives. It is going to happen. It is how the team reacts that is key. Not every moment is a "drop everything that you are doing and work on this." When stuff happens, it is up to the team to analyze, collaborate and ensure there is a complete understanding of what impacts there are to adjust. Taking work out of a sprint so as not to impact capacity, move it to the next race as it is not as critical as initially thought or prioritize for future releases.

    Or the teams will throw in much work in the sprint without adequately following an effective and consistent pointing process or they don't understand their velocity. What happens with that is usually the Burndown chart looks more like a city skyline then a slope with a considerable drop at the end because incomplete tickets move to the next sprint. From there, it just snowballs out of control, which impacts everyone in the team. The sad thing is that it becomes the norm, and people become complacent.

    It is not a matter of throwing work in and seeing what comes out. Speed is high, and eventually, a good running team will be able to accomplish great things on a faster schedule. It is about setting a good foundation to get there. Getting speed for the sake of it will lead down a road that will not end well for anybody involved.

    The organization is not set up

    The fear of change is compelling. Usually, humans don't like to do something different. As long as they are comfortable, they are right. "It has worked before, why do something new?". Jeff said it best in his book "Change or die." Going on a deeper level, it is evolution. We all know we can't stop that from happening in the world, so why be so closed-minded to evolve the organization? It is more than just having teams running sprints and developing code while the rest of the organization is not in the same mindset. Think of it like two cars going down a road, and they have to go at the same speed. Now one of those cars is the new Lamborghini Vision GT V12, and the other is a 1985 Chevette. Yes, they will be able to get to the destination, just not as fast as they could go. So to partly evolve won’t help things, in the end, will only slow down the value that it could achieve while competition could pass.

    I had similar fears, and I overcame them. There are some of my former coworkers that would be pretty impressed that I have become an Agilist.  How did I overcome it? Well, one, as stated earlier, I did it and two education. Reading, courses, and talking to others have given me the insight to see the benefits and how to apply proper change management to get others down the path.