Riddle me this:
Q – What’s the #1 difference that an agile approach gives you versus old-skool software development methodologies (hint clue’s in the name)
A – Quickly or “agilely” getting working code into your end-users hands
It’s this answer that an awful lot of people miss, and it’s why I propose the first amendment to the Agile Manifesto:
“Any agile process should strive to get working software into the hands of end-users as quickly as possible.”
Let me now explain my reasoning:
There is an awful lot of guff talked about agile, for example, I’ve held my head in my hands after reading some recent blog posts discussing Cynefin and complexity thinking.
This sort of pontificating rubbish is what gives the consulting industry a bad name. 
The main elements of developing software are the same as they’ve ever been from the Waterfall method on down – Requirement gathering, Design, Implementation, Verification (Testing) and Maintenance. Agile (in any of its forms) isn’t a silver bullet and doesn’t magic away any of these elements, it’s just a different way of mixing these basic ingredients to build the same cake.
To stretch the baking metaphor – proponents of agile will tell you that with a Waterfall methodology you might end up with a Dundee cake, when the users really needed an Eccles Cake. This is exactly right, but the fundamental point is you’re only going to know the users wanted an Eccles Cake if you show them the first slice of Dundee cake, and they say “I’m sorry but you have misunderstood my requirement”.
So what? The point is that only the end-user can know if the product works for them. However, often the end-user never sees the product until the end of a 12 month development phase, much like the Waterfall method. What gives?
This problem is common in web-development. You win a nice fat contract to build out a site for your customer (lets call them AcmeCorp). The dev-team apply their shiny agile methodology and ship working code to AcmeCorp every few weeks. AcmeCorp looks at it and supplies comments etc, you ask for clarifications, get more requirements and so on and so forth.
12 months later AcmeCorp launches their shiny new site, but it doesn’t get the traffic they expected, or users don’t like the features, or it doesn’t appeal to the target demographic. Spot the problem?
You might as well have managed the project Waterfall style, you did 12 sprints/iterations
/leans/kanbans/cynefines, but from the End-User point of view, it was a big-bang delivery. You’ve been doing CAT (Customer Acceptance Testing) when you should have been doing UAT. Arguably there may have been some benefits about getting feedback from your Customer, but if you are not getting feedback from End-Users as early as possible in the project, you’re asking for major trouble.
Conclusion
Agile teams must strive to get feedback from the end-users, not just the customer, as early in the project as possible. As the feature you and the customer are convinced is the killer-app, may well be something your end-users don’t care about, or don’t understand how to use effectively.
UAT is the name of the game, and Agile teams should impress upon their customers the importance of putting the product under the noses of the real end-users as early as is feasible.
Convivial Coding 