- [Narrator] The concept and design phases
in Waterfall development
tend to produce heaps of documentation, user flows,
project milestone documents, and really everything else.
Agile is about leaning down
all those aspects of development,
which includes documentation.
By the design phase of an Agile project,
the technical team has a good understanding
of the product they're building.
So they'll need some documentation,
although it'll be a lot less than in a Waterfall project.
So when do we document?
How much is enough?
And when have we gone too far?
Typically it's a good idea to have a short document
with your project standards.
This can include how to write version control commits,
user stories, really anything that needs to be standardized
across the team.
A few simple rules about formatting shared information
goes a long way in minimizing headaches
and confusion later on.
You'll also want to have a document
that has technical designs
and decisions that have been made.
This'll keep the big picture clear
without being weighed down by minute details.
Now, the question is when to defer documentation.
The answer to this will depend on your project,
but I'd suggest
looking to Uncle Bob's First Law of Documentation.
"Produce no document unless it's need is immediate
and significant."
So if the answer is no,
don't document until you feel it's absolutely necessary.
When you think about it,
that's actually a pretty good axiom
for considering writing anything in an Agile project,
including code.
Now just because Agile development
runs on the light side of documentation,
doesn't mean it's sloppy or not maintained.
Anytime you have significant changes to the project
or important technical decisions,
they should be updated in your project documentation.