Documentation and agile IT projects: never the twain shall meet?

What is the place of technical documentation in agile projects?

During one of the projects I was running, a colleague came up to me and said that we could not call what we were doing ‘agile’ bearing in mind the technical documentation that the client had requested of us as we were designing this computer application for them.

It must be said that compiling documentation is not usually the favourite task of developers, who may be tempted to try and find a way of dispensing with the task altogether.

I did not see things the same way.

As often happens when a new approach is launched, everyone has their own interpretation, and the meaning of each keyword changes in accordance with people’s experiences. If we’re not careful, we can encounter some serious obstacles when communicating with each other.

There’s a simply way you can test for this – with the people around you. Ask a handful of people what they think when they hear a given word. That word can be mountain, crockery, holiday, quality. The word itself doesn’t matter. But you’ll soon see that everyone thinks differently.

To avoid misunderstandings over working methods, I tend to use a main source that is our ‘reference’, which if required I then tailor to specific project needs. The most important task is retooling the words, in conjunction with all the project stakeholders, to fit the present context.

So following my colleague’s outburst, I scurried back to my two main sources to clarify what is meant by agile working. These were:

1. The Agile Manifesto

2. The Scrum Guide

Under the Agile Manifesto, "working software" is deemed more important than "comprehensive documentation".[1]