There's nothing in any Agile practice framework or philosophy that says that you shouldn't document. However, writing documentation that's obsolete the moment it's written is just waste. The solution is to write code that doesn't require formal documentation. 1/
That goes way beyond just picking good names for things (though that helps) and adding comments (which usually don't). The code has to be the simplest possible solution to the problem in front of you and structured for readability. 2/
Well structured microtests demonstrate how the code should be used. Well-structured acceptance tests show you how the larger subsystems and services work together. Both of these are better than formal documentation because they adapt to changes in real time. 3/
Code that's structured to reflect the structure and communication within the business is self documenting if you understand the business. Understanding the business is an essential part of programming. If you don't, then learn. 4/
The programmers have to fanatically enforce modular boundaries and well defined portals into subsystems. If you do all the above, the need for system-level documentation is virtually eliminated. 5/5
