Tl;DR: Yes, it should if you practise technical excellence. Sadly often it doesn’t.
The current most popular Agile framework Scrum mainly focuses on process quality and project communication. If you get yourself a project manager transitioning to Scrum Master you will be in trouble, because they have no clue about internal or structural quality and why this is so very important in Agile product life-cycles.
According to Scrum it is up to the team to increase product quality:
During each Sprint Retrospective, the Scrum Team plans ways to
increase product quality by adapting the definition of “Done” as
This sounds pretty good on paper, but as Scrum focusses mainly on the process. The technical product quality could become an oversight. Going faster and faster, while making the code worse and worse. Trusting blindly on developers to improve code quality and having the skills for this, fighting quality or executing quality practises under time pressure is a dream that is just not true.
Therefor other Agile frameworks often mention quality practises. The best known are the rules from ExtremeProgramming: Pair-programming, TDD, Refactoring, etc..
I like how the LESS (Large Scale Scrum) team puts it:
Organizational Agility is constrained by Technical Agility
Most companies starting with Agile forget about the technical part. Therefor practising technical excellence as described in the Agile manifesto is a must. Your organisation can be o so flexible, but if your product resists change on a code level, was it worth it?
Continuous attention to technical excellence and good design enhances
One of the manifesto signees, namely Robert C. Martin is fighting to improve the code quality skills of developers, with his books Clean Code: A Handbook of Agile Software Craftsmanship, The Clean Coder and Agile Software Development, Principles, Patterns, and Practices. I truly believe it is necessary that an Agile coach teaches the skills described in these books to the development team, but in the real world I only have met a few who do and who really understand the impact of these practises. To often they trust the developers to know, experience shows they don’t, even if they think they do.
Be sure to find an Agile teacher, coach, Scrum Master that has been either an ex-Developer, ex-Tester or worked in a team that practiced technical excellence. ex-Project managers are probably the worst candidates, although they might be better in resolving organisational impediments. Which might be the biggest hurdle in getting started with Agile in some bigger companies in the first place. But for small teams starting with Agile, focus on technical quality will benefit them greatly!
Why am I writing this, because I have seen multiple successful products developed non-waterfall at different companies. Where the end result was that the teams came to a grinding halt when it comes to adding new feature to the product. Fixing one thing would mean breaking something else. The nature of the Agile process does not by default deliver a good structural maintainable and extendable product, certainly not Scrum. This is the biggest trap if you ask me.
The second biggest trap is deadlines. Even if the team does all the estimates taking into account good quality practises. Most product managers will commit features to clients. Putting a team under time pressure does not help with delivering high quality code. Still most companies do this even if they are very aware they shouldn’t. This is because clients also need to pitch internally to get budget, leading to roadmaps and deadlines. I think we should revisit Agile sales pitches.