The final behavior is “Favor Automation over Documentation”. This, rationally, leads a lot of folks to think about the agile value, “Working software over comprehensive documentation” and while I am down with that, this behavior extends beyond focusing on creating working software over creating extensive documentation.
Favor automation over documentation is, to a great extent, about reducing friction - reducing the cognitive load and minutia required to get the work done, allowing you to focus on the value being delivered over the means of delivery.
There are opportunities for automation all around us. The three steps it takes to get your app running locally can be put into a script and executed with a single command. That wiki page that details every step it takes to get a new development machine set up can be automated (or perhaps containers are an option). There are tools that will link your source control to your build pipeline and work tracking system, reducing the administrivia associated with each change while keeping you compliant. Your test runner can be configured to run only the tests associated with the files you changed - fully automated or when you say to do so. Your work tracking system can alert you when you are over your WIP limit. The list is nearly endless.
Personally - one of my favorite implementations of automation over documentation is when the documentation can be automated. I have been and continue to be a strong advocate for “Behavior Driven Development” or “Specification by Example” where plain english descriptions of how we want the software to behave become fully automated tests that validate the behavior.
In future articles, I’ll share more on tools and techniques related to favor automation over documentation.
Who do you know that would benefit from reading this? Share it with them now.
And if you want early access to these articles, come on over to https://docondev.substack.com/ where I’ll be publishing articles a month or two ahead of other platforms.