There are many, many advantages to using Agile development and Continuous Delivery when you develop software. I’m not going to go too deep into the perks for developers and managers since many people have already done so much better than I ever could.
No, I am going to tell you why, in my experience, Agile development leads to vastly superior user help.
Waterfall development: a personal history
The software I document used to use waterfall development. This means that a major new release came out every two to three years, containing all the new features developed since the previous version.
Ideally, the new features would be tested and documented as they were being developed, usually towards the end.
This is only the theory.
In practice, we had two cases:
1. dev teams who didn’t realize how badly a timeline can drift over three years, finished the development six seconds before the deadline and had to rush testing and user help creation while barely repressing horrified shrieks
2. dev teams who did realize, usually after being burned very badly in a previous version cycle, looped the QA team and the tech writer in early so they’d be less impacted by delays. This gave them free feedback on the readability and usability of the UI, as a treat.
I don’t blame the developers in case #1, they were the victims of too many years of ingrained bad project management habits.
I love and cherish the people in case #2.
Shockingly, this method gave a less than ideal product. The new versions tended to come out unstable, requiring massive patches in the days and weeks following the release, wildly overworking the bug fixing and QA teams who then needed to curl up under a table for a week or two to soothe their nerves.
This was a recurring issue and very obvious to users, so they systematically refused to switch to the new version, forcing the dev team to keep supporting old versions long past the point of ridiculousness and reducing the amount of time and energy that could be poured into stabilizing the future version.
And then there was the user help.
For most of the version cycle, developers and subject matter experts either had nothing to give me yet or felt zero sense of urgency when it came to user help, so I had to entertain myself. “Just go document a pre-existing feature,” they’d tell me, and I’d go look for something that looked like it needed user help.
Here is where I should tell you that before I came along, the software in question had been around for two decades and had just about zero user help. There was tons of contents squirreled away in private filers and gigantic paper binders, but if you didn’t already know where it was, you were stuck, and if even if you did, you’d still have to do an ungodly amount of digging.
Anyway, in a distressing number of cases, I just could not figure out what the chosen feature did, and neither did anyone else because the one person who knew it had been retired for seven years.
And so I’d go dig into old PowerPoint presentations, find nothing, and ask someone too nice to say no to go look in the code to try and piece something together.
That was roughly 95% of my time.
The last 5% came in the month before the version was set to release, when three dozen new features were dropped directly on my head from a great height, sometimes with a nice little message along the lines of “btw, the feature is very broken atm so we don’t have screenshots 🙂”.
Needless to say, I was rarely satisfied with the quality of my output.
But then I was saved
One day, word came from High Up that this whole thing was a bad look, and everyone was to switch to Agile development. We were to use a continuous delivery pipeline, with a new version every three months.
We had six months to prepare.
Cue angelic choir music, and also a slight wave of panic because six months is really not very long to accomplish anything where your starting point is whatever you want to call what we had going on.
Fast forward a year, the first continuous delivery version of the software came out, and it was stable.
It just worked. It didn’t freeze or crash or spit out an endless waterfall of error messages that filled up your screen in seconds.
And the user help was good.
Since each new version had just a few new features, developers and SMEs had to do a lot less juggling and could focus more on each feature. They were less stressed out, which resulted in a generally friendlier atmosphere. Everyone had more time and more brain space to dedicate to things previously considered non-essential, like having a UI a human can actually read and user help.
I was invited to progress meetings where my feedback was wanted and welcome. I could follow the new changes to existing features as they were happening and edit the user help on the fly. I didn’t have to stumble upon changed by accident to keep the help up to date anymore.
Suddenly I had SMEs contacting me directly to ask when I was available for demo and a chat. I didn’t even have to chase them down! They had time for me. They gave me thoughtful and relevant feedback. They gave me screenshots without even having to ask.
(Some of them did, at least, there was still a pretty large contingent who tended to forget that I existed or just didn’t care, but this is a feel-good story so let’s ignore them.)
And best of all, since SMEs now spent more time with me, they started getting curious. They started asking if maybe they could write their own help. They nodded along as I explained why I’d need to spruce up their content. They asked to see the user help creation software and they actually started using it! This was helped along by the fact that we switched authoring tools around that time and I was evangelizing the new tool to anyone who stood still for more than five seconds.
(We still use this tool, I love it like a son, you can request a demo here.)
Before, I was on my own, armed with a shovel and a useful inability to recognize when people were trying to tell me to go away. Now I had a team’s worth of budding documentarians and a central place in the development process.
Now, it’s four years later (five? who knows, time is meaningless) and I have over fifty registered users in the authoring tool. They’re not all very active, but they all took enough of an interest to try, which would never have happened if we hadn’t switched to Agile.
Where was I even going with all this
Even the world’s most accomplished technical writer can’t work alone.
To create good user help, a tech writer needs a few things: information, support and time :
- Without information, the user help is incomplete
- Without support, it’s irrelevant
- Without time, it’s both.
The more stressed out the whole team is, the scarcer those three resources are, and the lower the quality of the user help is going to be. If the user help is bad, it reflects badly on your product.
Lost users can’t find what they need on their own, they call the hotline, driving up your costs.
If enough frustration builds up, they move on to another software entirely.
It is in the best interest of any software editor to have good user help, and creating good user help is vastly easier with Agile.
The use of a writing tool designed to encourage this transversality and this collaboration is therefore an undeniable plus.
