
Why is Agile Software Delivery so hard?
Book your free Breakthrough Call to discuss this topic or any issues you are experiencing.
Why Is Agile Still So Tough to Master?
Agile: Simple on Paper, Complex in Practice
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Mindset Shift: The Real Challenge
A Personal Example: Turning Chaos into Collaboration
- What did you do yesterday?
- What are you working on today?
- What’s blocking you?
Agile Values in Action: It’s About People, Not Process
Why Agile Still Feels Hard for Most Organizations
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
- Continuous learning and feedback
- Psychological safety and trust
- Empowering teams to own their work
- Leadership that models Agile values
Ready to Make Agile Work for Your Team?
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.

