Tom Breur
21 June 2015
Most developers hate
documenting. It’s the kind of job we postpone until Friday afternoon, 3 PM,
when we’ve completely run out of steam… guess what? Somehow it doesn’t get
done. Duh. The prejudice that Agile implies no, or a lack of documentation is
one of the reasons people are sometimes hesitant to give it a try. Especially
those who spend a lot of time maintaining software.
Agile is about maximizing
the work not done. Does that imply we shouldn’t spend any time on
documentation? No. Not at all. Because we want to eliminate waste as much as
possible, you should always be suspect of documentation that has a shelf life
that expires as soon as your solution goes into production.
Occasionally, it can make
sense (especially in geographically distributed teams) to create documentation
that developers share “just” for the time of development. But that would be the
exception rather than the norm. By and large, when Agile teams create documentation,
this is to enable maintenance to a solution that is in production.
As per the Agile
manifesto, we strive to create
output at a sustainable pace. Production solutions without the accompanying
documentation can quickly turn into a time sink when someone else needs to make
changes, or even when it has been a while you created it yourself. This is why
“documentation” really (really!) needs to be either a habit, or a part of your
Definition of Done (if you’re doing Scrum).
Documenting work in
progress? Meh. Maybe not. Preferably not. But if so (if you feel you “need” it),
make sure this improves your throughput. And if it does: great! Documenting to
facilitate maintenance: yes! Absolutely. Omitting that critical part of your
work reminds me of an “Après nous le deluge”
mindset – not something I wish upon my colleagues!
Odd couple? Yes.
Incompatible? No!!
Good to hear someone take a plead for documentation. Maximize the work not done and eliminate waste, yeah. I vote for that. In addition to the point you make, I believe good refinement is crucial. Within my context it was not until we start writing the "wishes of our stakeholders" down, when we learned that we were missing a lot of details. That we were designing processes with a high focus on input, and were neglecting the output completely. How is that for introducing waste? So I believe its good to write things down, make it fit for purpose. So if something is complicated use more words and schematics than you would do for a standard solution, but use it during refinement, development, test and handover.
ReplyDelete