This is a common misconception of those inexperienced with agile, who choose this methodology on the basis of thinking that their project can be delivered more quickly and easily by avoiding documentation. But agile is not an excuse for skipping documentation. While some information will always need to be captured in written words, there are techniques that can be used to reduce documentation but will still give the customers what they want.
“Agile means more talk and less documentation, doesn’t it?”
This is a common misconception of those inexperienced with agile, who choose this methodology on the basis of thinking that their project can be delivered more quickly and easily by avoiding documentation. But agile is not an excuse for skipping documentation. Documentation is just as important in agile projects, though it is often more focused and condensed. The level of documentation needs to be appropriate to the particular project you are working on and the level of maturity of the team.
I was recently supporting a company implementing a new system that was a large, complex solution. The team was newly formed and most were fairly new to agile. Fortunately, in this instance they were co-located.
One of the many conversations that we had was around the amount of documentation. It went like this:
Ben: “Hi, Leanne. One of the things I have noticed is that we write a lot of documentation, and I thought agile was all about writing less. I have brought this up in our retrospectives but I don’t have anything to compare it against. Can you help?”
Leanne: “Sure, Ben. Let’s just look at your project and see if we can come up with some suggestions.”
I needed to consider the question in the context of the project he was working on.
Leanne: “First, you are all new to working with each other, aren’t you?”
Ben: “Yes. Most of us are completely new to agile as well and have not worked on a project like this before. We are all a bit nervous, to be honest, and don’t want to show how little we know or to rock the boat. We only came together at the beginning of the month and have had three two-week iterations.”
Leanne: “OK, there are a couple of things we can look at. First, if you are a new team, you probably haven’t become a fully performing, close-knit team yet. You are still getting to know each other and building up trust. This is often observed by seeing people follow up conversations with emails so they have a documented record, for example. This should reduce over time as trust builds. Try reducing documentation with those you feel you have built up the most trust or those with whom you have a good rapport. Lead by example—when others see it working for you, they are more likely to want to try it.“
Ben: “Thanks. That’s an easy suggestion that I hope will get immediate results.”
Leanne: “Second, if the majority of the team is new to agile, you are probably reverting to what you know rather than how you might want to think about doing things in a more agile fashion. Take your requirements eliciting and documenting, for example. You are probably capturing everything you know, asking lots of questions, and writing down lots of answers. Maybe you want to start using a conversation rather that writing it all down.