-
0
0
On February 11-13, 2001, at The Lodge at Snowbird ski resort, overlooking the Wasatch mountains of Utah, seventeen independent thinkers, self-described as “The Agile Alliance,” met to talk, ski, relax, and try to find common ground.
Representatives included those with backgrounds in #ExtremeProgramming, #Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation heavy software development processes.
What emerged was the Agile ‘Software Development’ Manifesto, a set of values (seen in this image) and the “12 principles of Agile Software”.
I have written several articles discussing each of the principles in detail, examining their validity in today’s world. The intent of this article is to discuss the value of “Working Software over Comprehensive Documentation.” It is the third in a series of 5 values articles covering the values, including a common fallacy and some detail and practices I encourage you to take in adopting each value and an agile mindset.
The Values of AgileManifesto.org
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Working Software over Comprehensive Documentation
Most of our team’s time should be spent ensuring those things being built are of working order, free of defects, and functioning in the way we designed and expected them to. Unfortunately, oftentimes we get bogged down in documenting the processes, focus on understanding and fixing all the requirements up front, and impede our own progress with the tyranny of the details and gold plating.
We certainly need to ensure that there are user manuals available to our customers and technical support peers should they need to figure out how to use a particular module of our products. However, we need to get to a point where our main efforts are focused on ensuring the product works and is intuitive, not that we can make it work when it’s not.
Additionally, all the documentation requirements of our organization need to be refined and updated on a regular basis to ensure we are no longer asking our teams to spend significant amounts of time on work that will never be used or are part of an antiquated process. We need to look for ways to alleviate stress from our teams and ensure they have the environment, time, and space to deliver quality products quickly. Delivery often becomes difficult and/or severely delayed when we ask our teams to deliver comprehensive documentation on top of the product that we’ve asked them to build.
Instead, consider embedding technical writers within the teams or as a shared service across several teams if you are not already doing so. Teams with embedded writers can then estimate the documentation effort into their estimates of work and we can measure, improve, and remove significant delays in the process. Those within a shared service can see what work is planned in the pipeline and plan the documentation, accordingly, alleviating some of the delay – which can often be a full sprint or more – and deploy and/or release the product features faster and fully documented.
Another opportunity would be to have your team members pair work with these technical writers. This would expedite the technical writers experience with the product, allow for them to write as the product is in development, and likely encourage paired team members to pick up another skillset that improves their own value and their value to the company. In the instance you do not have or hire technical writers, leaving documentation efforts up to the team itself, you can encourage pair work from within the team where one develops while the other documents the functionality. Much like previously mentioned, this paired work would build upon the skillsets of all parties involved.
Regardless of the practices we incorporate into our day-to-day business, to truly embody this value into our agile mindset, we must value the time we spend creating the products we are building over the time we spend documenting them. We must look for every opportunity to eliminate excessive documentation, throughout the development process, to provide a greater focus on quality and a higher value product for our customers.
