Why your users hate Agile development (and what you can do about it)

The article argues that developers tend to value Agile for iteration, flexibility, and earlier feedback, while users often experience it as uncertain, open-ended, and hard to plan around. It says the main friction comes from budget predictability, technology predictability, and the feeling that Agile can look disorganized or never-ending.

It also says developers can reduce that friction by building trust step by step, giving regular and increasingly accurate updates, talking to all stakeholders, making the impact of changes clear, and adopting Agile gradually when the organization needs a cultural shift.

Reading notes

#

• Developers like Agile because it makes feedback earlier, lets them handle one thing at a time, and can expose problems before they grow.
• Users often want a clear budget answer, but Agile projects can only give an estimate that changes as the work changes.
• Trust matters because customers who know the developer are more willing to accept flexible planning.
• Fixed-cost and fixed-duration projects are presented as one way to give users more predictability.
• Regular progress updates can make the project feel more concrete even without a fixed deliverable date.
• Users also want the software to solve the business problem and they worry about scalability, maintenance, and late surprises.
• Big Design Up Front can reassure sponsors, but it can also become a rigid commitment that ignores later discoveries.
• Some users read iteration as disorganization and think Agile is a process without enough estimates, documentation, or plans.
• Agile can also feel open-ended, because clients often want to know exactly what they are buying.
• Transparency and planned sprints are described as ways to let clients control how far the work goes and when to stop.
• Agile can increase workload for users, who have to collaborate, review, and prioritize work.
• The article says bad Agile experiences can also come from culture, not just misunderstanding of the method.
• Developers should talk to all stakeholders, not only managers, because day-to-day users may have different needs.
• Change is hard, so the article recommends introducing Agile in incremental steps and proving success along the way.