A Bug-Fix Cycle at Project End Is Good for Everyone
By Ben Minson
We have a customized flavor of Agile development, and today as I was talking to one of the program managers about the next few cycles of work in a particular project, he said that the work in the last cycle or two was not yet defined. That’s fine; at least in our version of Agile, the work that was defined generally at the beginning is solidified as we go. Development is planned on an iteration-by-iteration (or sprint-by-sprint in some vocabularies) basis and more broadly on a cycle-by-cycle basis. A cycle contains several iterations of work, and the idea is to have a body of code that can be released to and used by the customer at the end of the cycle. The interaction designers prototype at least one cycle ahead of development.
The manager hopes that most of the new development work will be done at the end of the second-to-last cycle. As he talked, I got a little idea: What if the last cycle of an Agile project were reserved for bug fixes? We have hardening periods before the release for fixing bugs and for the testers to make sure they’ve exercised and proven the functionality that was developed at the end of the cycle. But what about an overall hardening cycle for the bugs that haven’t yet been addressed throughout the entire project?
This would benefit the team and the customer, but I wouldn’t be talking about this if I didn’t think it could benefit me, the technical communicator.
Because, in Agile methodology, releases follow closely on the heels of the end of iterations and cycles, it’s challenging for the technical communicator to have the documentation for that release absolutely finished before the code has to start rolling toward production, let alone for the testers to give it a going over.
If there was a bug-fix cycle (or at least iteration, depending on the overall length of the project) at the end, this would give the technical communicator some time to catch up on those final details. Bug fixes generally result in functionality working the way it was designed rather than in a new implementation. Of that second category, much of the code tweaking is behind the scenes and would be transparent to the user experience. This means that the technical communicator could focus on making documentation accurate and wouldn’t have to worry about changes taking place during the bug-fixing frenzy.
So if you’re in an Agile shop, it could very well be to your advantage to put out the idea of hardening iterations or cycles at the end of projects. These periods would have to be included in the program manager’s project plan from the beginning so that the project wrap-up date isn’t delayed. You’d have less pressure, I’m sure the testers would breathe a little easier along with you, and the customer would be happier with the result.
Ben Minson is a technical writer and trainer in the information technology arm of The Church of Jesus Christ of Latter-day Saints. He produces online help, written manuals, and training in person and over the Web. Ben holds a bachelor’s degree in English with an emphasis in Professional and Technical Writing from Utah State University. He is also a member of the international Society for Technical Communication. Ben’s blog on writing topics can be found at http://www.gryphonmountain.net.