The Agile Manifesto was partly borne out of valid frustration with “document first” software development methods that seemed to care more about the font size in the documentation set than the value of the software that was delivered. This led to the statement that we value “working software over comprehensive documentation” and a healthy focus on the value of everything we do in software development.
As is so often the case though, we probably overcorrected and we're now often in the situation with 8 year old projects that have lost sight of their fundamental design principles and rationale leading to the very sort of “cargo cult” behaviour that the Agile movement exists to remove. In my design and architecture work with Agile teams, this is something that (as a self-confessed “over-documentor”) I've been working to resolve for years.
In this talk, I discuss what architecture and design information is useful to capture and why. This leads to a set of tangible practices and guidelines to help teams find the right balance in their particular situations.