Extreme documenting

We’re facing the challenge of how to write documentation in an agile development process. Yes, you could argue that documentation is muda, but we want it nevertheless – it helps us work around the situation of having distributed teams in different time zones and offices, so the simple “go and ask” solution is not working.

Now the big question is, if it makes sense to start writing documentation – explaining where you have to click in order to achieve what – in early phases of development before the UI has stabilized. Plus, we did not have a technical writer from the beginning, so not only the content, but also the wording and structure will change afterwards. So it sounds like it’s a lot of work (which is way less fun than writing code) that has to be changed and redone anyway, so our first thought was: we don’t want to do it. No.

Nevertheless, we decided to have this minimal, incrementally changing documentation in place. Why that?

  • It helps the product owner to test and sign off the implemented stories (so it has an immediate benefit)
  • It’s basically only a “How to demo” enhanced by a “and what is it good for” and does not require too much work
  • I’m actually afraid of having the whole documentation only done afterwards. Chances are high that you forget something – if you do it as part of a story, it’s very easy to check that documentation is done
  • It guarantees that the documentation is finished at the same time as the product and you don’t need some additional time afterwards. Or, to say it in agile, it allows us to work at a constant pace indefinitely

Basically, it’s the same as for developing software – you know that you’ll have to change parts of the code as new requirements are coming in, but sitting there and twiddling thumbs until all the requirements are finalized is not an option.