The Discipline of Quality
Agile developers take a test-first approach to development where you iteratively write a single test and then just enough production code to fulfill that test. This is easy to say but in practice requires significant discipline because it's very easy to assume that you, or someone else, will do the testing later. It's also very easy to assume that you're writing great code and that you don't really need to write a test for this "obviously simple" code that very clearly could have nothing wrong with it.
As I described in Agile Testing Strategies (www.ddj.com/development-tools/196603549), many agile teams choose to have an independent test team doing investigative testing in parallel to the construction efforts. This requires discipline on the part of the development team because the tester(s) will regularly provide defect stories that should be treated like new requirements to be prioritized and put on their work stack appropriately. True defects, as opposed to potential new features, should be addressed by the team quickly to avoid increasing their technical debt. Traditional teams often let defects build up throughout the project, if they even detect them at all, with the intention of addressing them at some mythical point later, a very risky, expensive, and undisciplined way to work. Following this approach, developers very likely will not provide them with detailed specifications, as it's not required for investigative testing. Instead, testers are provided with a new build on a regular basis, at least once an iteration although nightly is even better, so that they can work with the most recent version of the system available. Handling this sort of "chaos" requires significant discipline on the part of investigative testers.
There are several quality-related development techniques that require significant discipline. First, it is common for agilists to follow shared coding conventions, database standards, and even documentation guidelines, requiring agile developers to conform to the agreed to norm instead of simply following their own preferred approach. Second, it requires great discipline to refactor only what is needed right now for the task at hand and not fixing a lot of stuff that should be done at some point. Third, the discipline of requiring that builds be successful before continuing on with the development of new functionality is absolutely critical because it promotes code convergence within the team and a continual focus on quality.
