Changing our documentation system was driven, ultimately, by personnel reasons that resulted from our switch to Agile:
House Rule: Teams must be cross-functional generalists
As part of Agile, our job titles and formal duties were dropped, so that we are all considered “Product Developers”, all collectively responsible for designing, coding, testing, and documenting. While we all bring strengths and expertise, we are no longer dedicated role specialists. Underlying this is the belief that everyone can and should write, which is key to the participatory model of social media: “Here comes everyone!”
So, the critical change is that our approach to Agile demands that all SCRUM team members be enabled to create and update documentation, to achieve Definition of Done.
Info Dev lost half its writers
Our Agile consultant warned us to expect to lose a third to a half of our talent due to unhappiness with the new method. Ironically, all of our writers loved Agile: far from being dinosaurs who could not adapt with the times, they were lured away to other Agile shops and opportunities, such as consulting. So, losing half our resources (two out of four staff writers!), the few of us remaining were sure to become bottlenecks unless we could open the doors to wider participation.
No new writer hires likely
But Agile brought us deeper disruptions than a temporary headcount crunch. A documentation impact that we did not see coming was our Agile directive of allowing teams to decide how vacancies are to be filled, to best help them reach Definition of Done. This effectively means that a team can skip back-filling a lost writer in order to get another developer (which is more likely to increase team velocity). The new norm is to fill vacancies with junior programmers, who focus first on automated testing before being pulled into new code creation.
The resulting negative impact on documentation volume and quality will have to be heard from customers by Product Owners, and that will take time to become clear. Meanwhile, we remaining writers straddled multiple teams and watched our silo model of documentation production (where dedicated technical writers author in a specialized CMS) careen toward extinction.
But... why not solve it within AuthorIT?
Surely the most logical first response to this personnel crisis would be to revamp our existing implementation to work with authorship across the entire production group. Here are the barriers we found, the "Tool reasons", that kept us from doing so:
- Budget for licensing - We use AuthorIT on a terminal server, with floating licenses to support all writers working concurrently. It would cost thousands to buy extra licenses/support to cover concurrent work by all the teams, and the AuthorIT enterprise webserver version (designed for exactly this use case) costs in the six figures – quite out of our reach.
- Our complex implementation - Worse, the library structure we’d developed was too complex to just open to non-writers: the nested variables, embedded topic objects, template inheritance, object-oriented structure (such as hyperlink objects), and other features of the CCMS would be nearly impossible to simplify for casual users. Reimplementing our content library for safe and easy authoring by SMEs would be a huge project in its own right - as big as conversion.
- Forced migration looming - At the same time, we faced a migration within AuthorIT, from version 4 to version 5, a project outside the scope of our active sprint work. To get to version 5, we faced reimplementing our publishing templates and macros, and we had several blocking issues on our test migration database. In other words, we had been deferring a large amount of non-sprint work, completion of which wouldn't have us any closer to an Agile solution.
That last point worried me. Before too long, we could face having our production library on an unsupported version of the CCMS, an unsupported version of Word, and an unsupported version of Windows Server. Ironically, this was the exact situation we were in back when we converted to AuthorIT! A good time to jump.
Comments