Over the last few years Agile development has become the benchmark of progressive, bleading edge software development. The idea is to produce working software within a very short space of time, then build on that in subsequent deliveries. As a concept it works very well and brings many benefits:
- the customer sees working functionality very early in the development process and become part of the development team. Rather than signing off a specification then waiting months or years for the functionality (during which time requirements more-often-than-not change or develop) – the customer becomes an integral part of the development team and process.
- changes can be accommodated as the finalised functionality is not fully designed at the start of the process. The business requirement may be known but the intricacies of the functionality to meet that business requirement are developed, holistically, as the functionality itself develops. Changing requirements can be absorbed by this flexible approach without the need to stop and re-spec.
I have seen the good and the bad of Agile implementations.
The benefits were clear when, within an organisation in which I worked, Agile was trialled with a single team working on a single product release. The team were corralled together and had all the required expertise gathered in one place. We were focussed on a single product delivery with customers close-at-hand providing us valuable feedback throughout the development process. It turned out to be a perfect situation for Agile development and worked tremendously well.
I have also been a single author (or the lead of a team of two) providing the documentation cover for multiple Agile development (and Maintenance) teams. This was a nightmare as not being a part of any one team made it incredibly difficult to keep up-to-date with multiple fast-paced, changeable developments.
One statement in the Agile Manifesto’s statements has raised, for the Technical Author and others working within Agile teams, some interesting issues. The statement is:
Working software over comprehensive documentation.
When I first saw this statement I was under the impression it meant the removal of the full specifications drawn up under waterfall-style processes, or even the project-management type full project planning artefacts because, under Agile, planning is performed in short sprints (two weeks is the norm) and the functionality develops holistically over time.
I have seen this statement used by Agile projects to protect themselves from producing little, if any, supporting documentation. This becomes a ticking time-bomb as those with the functional and coding knowledge leave the institution or move to different areas of the business.
There is a time and a place for Agile. When implemented properly is an exciting, fast-paced development methodology that can reduce design and development times and result in a product that more closely meets the customer’s needs when it is delivered an implemented.
Done badly – it’s a confusing, lonely place for an author to be. Quickly developed functionality with very little supporting documentation can quickly get away from you if you have your eyes (and typing fingers) busy elsewhere. If you are not an integral part of the Scrum team product, you better have (or build) very strong connections within the analyst, development and test teams because you are going to need them!
A recent discussion on the ISTC Discussion board on LinkedIn titled ‘Tech writing using Agile – why are there no benefits?’ struck a chord within me as a number of authors raised the very same points that have kept me awake (at least twice!).
- The Agile Manifesto site.
- LinkedIn discussion:
‘Tech writing using Agile – why are there no benefits?’
- LinkedIn discussion:
I believe that many of the problems that technical writers encounter with agile are due to the fact that agile and scrum are done badly more frequently than they are done well. Would you agree?
What do you think?
Do you have an Agile success story or nightmare to share?
Have you worked with multiple scrum teams simultaneously? How did you juggle the needs of multiple teams?
What do your scrum teams produce in lieu of upfront functional and technical specifications to ensure your systems can be understood?