Below are my notes and highlights from this session at Write The Docs Europe 2016 in Prague. This is part of a series I wrote during the conference. This is not meant to be transcriptions and may have missed points made during they talk. They solely reflect my interpretations of the talk.
Postulating the Backlog Laxative
by Paul Adams
After a brief explanation of scrum, including its history from rugby. The bulk of the talk was about scaling up from a small team taking on new tasks not all of which may be engineering. This is typically the first pain point for a new tech startup as this is the first time where the focus is not just on making the product. This is the point where there are many options, a lot of them bad.
Crappy Solution 1: Don’t do documentation. You can carry on and you will be able to scale your engineering process without any problems regardless of the process you choose.
Crappy Solution 2: Make the fish ride the bicycle. Put your technical writers in the engineering team. This is one of the most common crappy solutions. This fails in part because the theory of scrum is that any story can go to any member of the team. Now you are spending a lot of time ordering stories that can only be done by one team member. The best technical writing results from the writer being involved from the beginning, but this results in a huge overhead in communication.
Crappy Solution 3: Always chasing the story. This puts the writers always one sprint behind, trying to document finished stories. This has the same communication overhead as crappy solution 2, but engineers are also required to now think back over things from the previous sprint.
The solution is found in going back to the origins of scrum, but not focusing on the scrum, but on the game of rugby itself. Rugby is actually two sub-teams with one target. Everyone isn’t in the scrum. In rugby the forwards get the ball and sap the other teams energy then the backs come with the ball and gain ground in the space the forwards created. The teams shouldn’t be merged, they have two different skill sets.
What we need is a distinct team that does technical writing and is empowered and enabled. This gets the core writing tasks out of the engineering team. The engineering team still has “write docs” as part of their definition of done, however they are responsible for just writing the first draft. This gets the docs team set up to take the ball over the line. The first draft gets us 50-60% of the way there and provides the information transfer required.
At crate.io they have said to the technical writing team, you aren’t required to be a scrum team, you are whatever you want to be as long as you have a clean interface with engineering. This allows them to help with documentation, conference submissions, blogs, marketing, etc. The writing team has chosen to organize as a kanban team because this allows them to service the incoming requests in a good ordering method. Parallel is important.
These simple steps improved the quality of documentation while respecting the various specialties:
- Separate the teams
- Get engineers to do the first draft
- Enable the writers to finesse and improve and finish the docs
- Stop the writers from chasing the engineers and have a clean hand-off