My son Alfie loves the Alfie books – for obvious reasons – so I know he’d be over the moon to win a piece of original art from the series.
(and sisters, obviously)
Working on a major training project in Qatar for almost a year has introduced me to the role and work of the Instructional Designer. There are many parallels between the ID and TA and it’s easy to see why people performing these jobs so easily cross between the two. Some example touchpoints I have observed:
The Instructional Designer considers and arrives at the best delivery method to provide learning to their audience. The Technical Author investigates and decides which format and channel is best to deliver information in a given situation.
Both consider the environment in which their outputs are used, the technology and tools available to develop and receive the information and training, and the time that the audience can, or is allowed to, devote to the information.
Audience and needs analysis
Both perform audience analysis to understand their intended audience’s level of understanding and knowledge at the point they begin the training or using the information. The ID / TA considers where the audience should be once the training or information has been utilised. The resulting gap acts as a benchmark for the development of the course / information requirements.
Course and Information outline plan
With the understanding of their audience’s ability before using the information or training, development tools and delivery channels in place the ID / TA then maps out the training and information requirements.
Reviews and delivery
After the first draft of the training / information is ready the ID / TA involves the wider team such as Subject Matter Experts and other project members to ensure the material is complete, correct and fit for purpose.
As I have become more involved in Instructional Design and the project management and delivery of e-learning courses my interest in, and estimation of this role increased. It is something I think I will get more involved in over my career. It draws on skills I have as a Technical Author and introduces new approaches, tools and delivery methods to help users perform.
To bring my understanding and ability in this area up-to-scratch I intend to work my way through a good proportion of the books listed in the link below. If you know of any other useful resources I would appreciate it if you’d pass them on.
The Agile process and its affect on persistent documentation – a work-in-progress or overlooked aspect introducing long-term risks?
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?