“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.

“I can help you with this. Let’s have a look at a couple of new requirements you want to document and have a go. Let’s write them with a minimum amount of detail using a user story format. Challenge yourself, even if it feels a little uncomfortable at first. Once you have written a couple, let’s present them to the team and ask their feedback. You may need to do this a few times to get the whole team on board.

“Your testers may also be writing full-blown test cases with step-by-step instruction, specific data, and the expected results. I can give them some coaching on how to use session sheets with charters and test ideas.”

Ben: “Wow, I can feel the weight of documentation being lifted already.”

Leanne: “Maybe we should try what I have mentioned first or the team may be taking on too much change. These processes will take a bit of time for the team to get it right.”

While I gave Ben some suggestions about where he and the team can possibly reduce the amount of documentation, there are still a couple of contributors that could likely mean more written communication. These factors are that they were working on a new system, this in itself is likely to mean more documentation, as there will be little re-use and everything will be unknown by the team.  Secondly due to the fact that they were working on a complex system again this will probably mean more documentation as these interactions will need to be understood by the team. One way to cut back on some writing is to create diagrams through brainstorming using a whiteboard.

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.