The Agile Manifesto revisited: part 2
So let us look at the second principle:
Working software over comprehensive documentation
This has never been a clear statement.
Optimistically, we can interpret this as meaning that we should measure progress in software development by seeing the software function in a demo rather than reading the technical specifications of what is being built. Also, we should spend less time in writing full specs and focus more on code development.
But that is only one interpretation. The traditional requirement to document code served two other purposes as well: documentation would make code easier to understand when maintaining it, and documentation was required to support operations, as in: what should I do when error code 632 appears. They are both valid concerns and although everybody realized that documentation was only a partial solution, that was still better than trying to operate and maintain a lot of undocumented code. And this has not really changed all that much.
XP (eXtreme Programming) has addressed this. Code needs to be so clear that it requires no documentation. In addition, code has to be covered by test code, contributing to making code easier to read and maintain.
So this principle could have read:
Clear, working code covered by automated tests over comprehensive documentation
But it does not. Contributing to a charge leveled at Agile software development: sloppy work practices, not enough discipline, allowing poor work. Add this one to the first principle where processes are discounted as less important, and you get the credible point that Agile software development ignores quality.
This is not just an impression. I have come to love agile software development more through the technical beauty of XP than through the more human approach facilitated by Scrum. Ignoring the pride generated by high quality is ignoring one of the key drivers facilitating self-governing teams. Which are not among the principles of the Agile Manifesto anyway. Scrum has not endorsed XP.
In fact, the main reason I have become a SAFe Program Consultant is because SAFe openly endorses XP at team level. The multi-functional teams in SAFe must use best coding practices XP proposes. Eat that, Scrum.
And there is one more point. Documentation is loathed by most programmers, but I still have not met a system engineer or service delivery manager who does not consult and make documentation, or at least knows (s)he should. The cavalier attitude to documentation means that the Manifesto for Agile Software Development blithely maintains the chasm between IT-development and IT-operations. This has not helped DevOps, an agile approach to bridging the gap between development and operations.
And it still has consequences. LeSS, the scaling agile model that stays as close as possible to Scrum, does not even talk about DevOps. SAFe, the scaled model based on lean-agile, incorporates DevOps lock, stock and barrel.