Memo:
Customer documentation
Since we
want to continuous deliver software, we must also continuous deliver the
documentation for it. If the user manual constantly is being delivered far
behind the functionalities, than the customer has software and no idea how to deal
with it. This by the way is alarming already.
Introduction
I have a
hard time to always be confronted on the fact that my recommendations are
structurally too much for a company. In fact, I think that every individual has
a hard time having that, because a company is mostly depending on more than one
person who makes decisions. So in short, this memo might be at first glance too
blunt to deal with. That being said, this memo could be a real good sketch to
have more success.
Current status
The only
thing we do now is add release notes to the user story, that’s part of the
definition of done. Other documentation is only technical and is been kept in
the user story. This documentation is mostly information on how the user story
is meant to be and is how it is evolving during the implementation. All
implementations are incremental, that means that full functionality is at the
end of all implemented incremental stories. And each incremental story is a
stripped version or working part of the full functionality. Each time we
deliver or finish a story, the user has something to work with.
The
developers have gotten knowledge of the user story by having refinement,
creating the user stories with their product owner and by collaborating within
the team during the implementation. That means that, if there is information on
the subject, it is in a minimum amount. This is just enough to do the
implementation well. That is the general idea right now.
After
publishing the functionality, a team picks up the new features and blend it in
the existing documentation, create ‘How to’ videos and produces manuals.
Future possibilities
If I think
of adding documentation to the user story, which tells the user how to deal
with the new functionality, I foresee a constant changing documentation with
adding new functionality. That’s because we implement incrementally. Also, when
we have delivered a piece of software in former sprints which is implemented
and documented months ago, it’s hard for a developer to change this
documentation, because the source code isn’t hooked on to the documentation.
The source code and the documentation (user manual) are two separate things.
Suggestions
To continue
after these explanations, I would suggest three things. These things are each
responsible for reducing work and reducing documentation changes. Also these
things are agents to get a better understanding of the functionality and
therefore better produced code. Let’s take a look at them:
· Let a key user frequently or
constantly spend time on a development team. This ensures that we make exactly
the software the customer needs. And therefore the minimum amount of time will
be spend on documentation. (Cause we don’t have to change it much)
· Also let someone who is responsible for
user documentation spend an hour a day or more on the development team. He is
at that moment in the middle of the change so everything is fresh by understanding
the functionality.
· Let a user experience (UX) colleague
frequently spend time on the team and work together. Not as we do now separately.
Currently it’s like this: the development team thinks they don’t need a user
experience guy much and the user experience guy thinks the same about the
development team. But this tight collaboration ensures us that we make the
software so intuitive that we have to document less. And that leads us to spend
less time on writing or altering one, in definitely.
The people
who are drawn to the team will give us good and quality documentation. On the
other hand there is a synergy step here. The development team gets better at
writing functionality, the key user gets better quality software, the
documentation is written due one on one collaboration with the developer (a
tester is a developer as well) and the user experience guy (or woman) is
working both with the key user and the development team all by working together
on the job. And that brings us very good quality software!
Summed up
And though
we only wanted better documentation, we end up with:
· a better process,
· better understanding of the program,
· better functionality, which becomes
more intuitive,
· no delay due documentation written afterwards
and
· of course what this has initiated in
the first place: good and fast documentation!
Postscript
I know I’m
speeding up too fast in contrast to the company and I want more than I probably
can get or accomplish, but this is the ideal picture of a good running software
development. This is how we get a good product and good documentation for the
customer (you may also read: good collaboration with the customer).
And finally
I really must point out that the more you spend on caring for development, the
more intuitive the software gets and the less the customer needs to learn and
read about it. We also need less courses to give to the customer. And if the
software is more intuitive the threshold becomes flattened for people who aren’t
specialized in, but want to have bookkeeping software.
