Driving Development

Recently Daniel Brolund posted an idea around something he termed User Guide Driven Development, it’s an interesting read and, you know what, he’s almost right. Almost. First up you should note that Daniel works for the company that created the application he name drops in his post, Bumblebee. However his approach did ring a few bells with me, as it would sit nicely alongside my belief that, when working in an agile development environment, you have to eschew traditional writing processes and aim to grab and pillage information from wherever you can, trickling into what will become the final publication. What I’ve realised is that by partly adopting the process suggested by Daniel we, the technical writing team, can be …

Continue reading

Retrospectives

Last week I spent most of my time facilitate our retrospectives, that is I spent a lot of time chairing meetings, encouraging and monitoring debate, and far too much time manipulating Post-It notes. Let me explain. Within the development group, we base our working practices on Agile development and part of that suggests that at the end of each release cycle you should hold a retrospective session to pinpoint things that went well, things that didn’t go so well and to assign actions which will help improve things next time. It’s all about continuous improvement and we do get a lot of benefit from them. Don’t be put off by the name, it’s essentially a debrief session that is focused …

Continue reading

Trickle and Blink

“There is no such thing as too much information” We’ve all heard this statement at one time or another, and in the internet age it’s accepted as a statement of truth. Which is shame as it’s completely wrong. Turns out, that you only need enough information, not all of it. A while ago I wrote up some thoughts on how to integrate an authoring team into an Extreme Programming (Agile) development group. The post Trickle vs Traditional outlined a basic way of building up the required content throughout the various stages of an XP release and, to save you re-reading that post, let me grab the crux of what I was saying: The trickle method relies on the ability of …

Continue reading

Trickle vs Traditional

The following is taken from current experience, fitting a Publications team into an agile (XP) development methodology. It’s very much a work in progress… ~ In a more traditional development environment, there is likely to be specifications and design documents on which you can rely. This is not the case in an agile development environment, with requirements focussed around user acceptance, and a heavy reliance on word of mouth (through pair programming) and shared knowledge. It may sound chaotic, it is not. Each piece of functionality is assessed and if there is not a direct requirement for a piece of functionality it doesn’t get done, similarly each piece of functionality is stated as a story, and will have an index …

Continue reading