It’s probably safe to say that only a very limited number of the few people who stroll past my blog each week were fans of the Bonzo Dog Doo Dah Band. Or even, while they might recall their 1968 hit single “I’m the Urban Spaceman” (which, I read somewhere, was produced by Paul McCartney under the pseudonym of Apollo C. Vermouth), are aware of their more ground-breaking works such as “The Doughnut In Granny’s Greenhouse”. So this week’s title, based on their memorable non-hit “Can Blue Men Sing The Whites” is pretty much guaranteed to be totally indecipherable to the majority of the population. Except for the fact that the BBC just decided to use it as the title of a new music documentary.
But, as usual, I’m wandering aimlessly away from the supposed topic of this week’s verbal perambulation. Which is, once again, about agileness (agility?) in terms of documenting software under development. No, really, I have actually put some solid thought into this topic over the past several months, and even had one or two of the conclusions confirmed by more learned people than me, so they are not (wholly) the kind of wild stabs into the dark that more commonly make up the contents of these pages.
Where’s The Plan, Dan?
One of the major factors in agile development is “stories”. Users supposedly provide a list of features they would like to see in the product; the development team evaluates these; and draws up a final list of things that they think the software should include. They then sort the list by “nice-to-haveness” (taking into account feasibility and workload), and produce a development plan. But they don’t know at that stage how far down the list they will actually get. Most products are driven by a planned (or even fixed) release date, so this approach means that the most important stuff will get done first, and the “nice to haves” will be included only if there is time.
It would be interesting if they applied agile methods in other real world scenarios. Imagine taking your car to the dealer to get it serviced. Their worksheet says a service takes two hours, and there is a list of things they’re supposed to look at. You’d like to think that if the mechanic doesn’t get them all done in the allocated time they would actually finish them off (even if you had to pay a bit more) rather than leaving the wheel nuts loose or not getting round to putting oil in the engine. Or maybe not having time to check if you need new brake pads.
Of course, every sprint during the dev cycle should produce a releasable product, so multiple revisions of the same section of code can often occur. So how do you plan documentation for such an approach? You can assume that some of the major features will get done, but you have no idea how far down the list they will get. Which means you can’t plan the final structure or content of the docs until they get to the point where they are fed up fiddling with the code and decide to freeze for final testing. You end up continually reorganizing and reworking sections and topics as new features bubble to the surface.
But whilst the code may just need some semi-mechanized refactoring and tidying up to accommodate new features, the effect on the docs may require updates to feature overviews, links, descriptions, technical details, tables of methods, schematics, code samples, and the actual text – often in multiple locations and multiple times. The burden increases when the doc set is complex, contains many links, or may need to support multiple output formats.
What’s the Story, Jackanory?
Each feature in the list of requirements is a “story”, so in theory you can easily document each one by simply reading what the developers and architects say it does. And you can look at the source code and unit tests to see the way it works and the outcomes of new features. Or, at least, you can if you can understand the code. Modern techniques such as dependency injection, patterns such as MVC, and language features such as extension methods and anonymous typing mean that – unless you know what you are looking for and where to find it – it can be really hard to figure what stuff actually does.
In addition, the guys who write the unit tests don’t have clarity and education as objectives – they write the most compact (and unrealistic in terms of “real world” application) code possible. OK, so you can often figure out what some feature does from the results it produces, but getting an answer to simple questions that are, in theory, part of the story is not always easy. I’m talking about things like “What does it actually do (in two sentences)?”, “Why would I use this feature?”, “How does it help users?”, and “When and how would you recommend it be used”.
Even a demo or walkthrough of the code (especially from a very clever developer who understands all of the nuances and edge cases) can sometimes be only of marginal help – theory and facts whooshing over the top of the head is a common feeling in these cases. Yes, it showcases the feature, but often only from a technical implementation point of view. I guess, in true agile style, you should actually sit down next to the developer as they build the feature and continually ask inane questions. They might even let you press a few keys or suggest names for the odd variables, but it seems a less than efficient way to create documentation.
And when did you last see a project where there were the same number of writers as developers? While each developer can concentrate on specific features, and doesn’t really need to understand the nuances of other features, the writer has no option but to try and grasp them all. Skipping between features produces randomization of effort and workload, especially as feedback usually comes in after they’ve moved on to working on another feature.
Is It Complete, Pete?
One of the integral problems with documenting agile processes is the incompatible granularity of the three parts of the development process. When designing a feature, the architect or designer thinks high level – the “story”. A picture of what’s required, the constraints, the objectives, the overall “black boxes on a whiteboard” thing. Then the developer figures out how to build and integrate the feature into the product by breaking it down into components, classes, methods, and small chunks of complicated stuff. But because it’s agile, everything might change along the way.
So even if the original plan was saved as a detailed story (unlikely in a true agile environment), it is probably out of date and incorrect as the planned capabilities and the original nuances are moulded to fit the concrete implementations that are realistic. And each of the individual tasks becomes a separate technical-oriented work item that bears almost no direct relationship to the actual story. Yet, each has to be documented by gathering them all up and trying to reassemble them like some giant jigsaw puzzle where you lost the box lid with the picture on.
And the development of each piece can be easily marked complete, and tested, because they are designed to fit into this process. But when, and how, do you test the documentation and mark it as complete? An issue I’ve come up against time and time again. If the three paragraphs that describe an individual new feature pass review and test, does that mean I’m done with it? How do I know that some nuance of the change won’t affect the docs elsewhere? Or that some other feature described ten pages later no longer works like it used to? When you “break the build”, you get sirens and flashing icons. But how do you know when you break the docs?
Is It A Bug, Doug?
So what about bugs? As they wax and wane during the development cycle, you can be pretty sure that the project management repository will gradually fill up with new ones, under investigation ones, fixed ones, and ones that are “by design”. I love that one – the software seems to be faulty, or the behavior is unpredictable, but it was actually designed to be like that! Though I accept that, sometimes, this is the only sensible answer.
Trouble is that some of these bugs need documenting. Which ones? The ones that users need to know about that won’t get fixed (either because it’s too difficult, too late, or they are “by design”)? The ones that did get fixed, but change the behavior from a previous release? Those that are impossible to replicate by the developers, but may arise in some esoteric scenario? What about the ones that were fixed, yet don’t actually change anything? Does the user need to be told that some bug they may never have come across has been fixed?
And what if the bug was only there in pre-release or beta versions? Do you document it as fixed in the final release? Surely people will expect the beta to have bugs, and that these would be fixed for release. The ones you need to document are those that don’t get fixed. But do you document them all and then remove them from the docs as they get fixed, or wait till the day before release and then document the ones they didn’t get time to fix? I know which seems to be the most efficient approach, but it’s not usually very practical.
Can I Reduce the Hurt, Bert?
It’s OK listing “issues”, but a post like this is no help to anyone if it doesn’t make some suggestions about reducing the hurt, in an attempt to get better docs for your projects. And, interestingly, experience shows that not only writers benefit from this, but also the test team and other non-core-dev members who need to understand the software. So, having worked with several agile teams, here’s my take (with input from colleagues) on how you can help your writers to create documentation and guidance for your software:
- Write it down and take photos. Make notes of the planned features, identifying the large ones that have a big impact on the docs (even if, from a dev perspective, they seem relatively simple). And while you’re snapping those pictures of the team for your blog, take photos of the whiteboards as well.
- Plan to do the large or high-impact tasks first. A task that has a huge impact on the docs, particularly for an update to an existing product, needs to be firmed up at least enough for the rewriting and reorganization that will take place to take into account the upcoming changes (and save doing all this twice or three times).
- Create a simple high-level description for the major or high-impact tasks that at least answers the questions “What does it do?”, “When, how, and why would customers use this feature?”, and “What do I want customers to know about it (such as the benefits and constraints)?” A mass of technical detail, test code, change logs, or references to dozens of dev tasks, is generally less than useful.
- Organize your task repository to simplify work for the test and doc people. Consider a single backlog item with links to all of individual related dev tasks, and a link to a single doc/test task that contains the relevant details about the feature (see previous bullet).
- Annotate bugs based on the doc requirements. Those that won’t be fixed, and those from a previous public release that were fixed and change the behavior of the product, are “known issues” that must be documented. Others that were fixed from a previous public release and don’t affect behavior go into the “changes and fixes” section hidden away somewhere in the docs. Those that are only applicable during the dev cycle for this release (ones that are found in dev and fixed before release) do not need documenting. Help your writer differentiate between them.
- Think about the user when you review. Docs and sample code need to be technically accurate, and at a level that suits the intended audience, but having them reviewed only by the really clever people who wrote the code in the first place may not ensure they are appropriate for newcomers to your product, or meet the needs of the “average” developers who just want to use the features. Especially if there is no “story” that helps the writer correctly position and describe the feature.
- Make time at the end of the dev cycle. You can tweak code and add stuff right up to the time you need to build the installer and ship, but docs have a built-in delay that means they will always trail behind your latest code changes. They need reviewing, editing, testing, proof reading, indexing, and various production tasks. And stuff like videos and walk-throughs can often only be created once the software stops changing.
While the core tenets of agile may work well in terms of getting better code out of the door, an inflexible “process over product” mentality doesn’t work well for user documentation. Relying on individuals and interactions over processes and tools, working software over comprehensive documentation, and responding to change over following a plan, can combine to make the task of documentation more difficult.
Common effects are loss of fluidity and structure, and randomization. One colleague mentioned how, at a recent Scrum workshop for content producers, she came across the description: “We’re in a small boat with fogging goggles riding in the wake of an ocean liner that is the engineering team”.
Was It A Success, Tess?
I was discussing all these issues with a colleague only the other day, and he made an interesting comment. Some teams actually seem to measure their success, he said, by the way that they embraced agile methods during development. The question he asked was “Is the project only a success if you did agile development really well?” If analysis of all the gunk in your project management repository tells you that the agile development process went very well, but the software and the documentation sucks, is it still a triumph of software development?
Or, more important, if you maybe only achieved 10% success in terms of agile development methods but everyone loves the resulting software, was the project actually a failure…?