A Business Case for Agile Instructional Design
Blog, Essays

A Business Case for Agile Instructional Design

“We are uncovering better ways of developing software by doing it and helping others do it.

  • Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

So reads the Agile Manifesto, originally composed for software teams. As a longtime instructional designer and business analyst running development projects via agile methods, substituting “working instruction” for “working software” above suggests a timely and welcome new approach to instructional design and development projects with rich benefits to designers,  clients and stakeholders. In this whitepaper, I’d like to explain something of the value of agile instructional design (ID) as I see it and how the agile mindset may be applied to instructional projects.

Agile is a set of values originating in software design and development that have spread to other fields, including instructional design. If I had to sum it up, in addition to the values cited in the Manifesto above, agile means incremental, iterative approaches focused on building bite sized pieces of usable work. Popular implementations of agile philosophy include scrum, used more for new project development, and Kanban, more applicable to ongoing work, and others.

Agile is contrasted against its predecessors, linear, waterfall methods which may be oversimplified as plan the whole project (as opposed to bite sized chunks), build the whole project, test the whole project, deploy the whole project, and fix what didn’t work – which hopefully isn’t the whole project.

In the instructional design and development context the agile vs. waterfall dialogue often pits agile against ADDIE, analyze, design, develop, implement and evaluate, the time honored, linear, waterfall approach that IDs grew up with from the 1950s to present. There is much discussion lately around ADDIE’s imminent retirement as practitioners question the continued relevance of what sounds like an obviously linear approach in our fast paced, changeable contemporary business environment, but this is probably premature.

Critics of ADDIE raise concerns that especially in large, complex (expensive) projects, a lot can go wrong between the identification of a business problem, the research and creation of a fifty page design document to solve it, and building and releasing instruction intended to solve the problem – not the least of which may be the lag time necessary to research, collate and approve fifty pages of specs.

The critique continues that software or instruction created and delivered via waterfall methodologies is often already out of date or otherwise mismatched to the problem it was designed to solve. But on the other hand, ADDIE supporters counter that the acronym was never intended to be taken literally, and that ADDIE can happen in shorter iterative cycles vs. one long process making it essentially an agile process.

The debate is academic, but it is probably useful to understand how the field is evolving.  There are plenty of IDs who get the job done effectively regardless of what method(s) they use. I’m not a critic of ADDIE or waterfall methods, which have their uses and variations. What is interesting is what IDs can add to their toolsets from the expanding agile toolbox.

Digging deeper into agile then, the opening sentence of the Agile Manifesto reads, “We are uncovering better ways of developing software by doing it and helping others do it.” This gets to the heart of the the agile mindset, which I’d summarize as non-dogmatically improving the ways we work by doing and team learning.

The next bit, “through this work, we have come to value individuals and interactions over process and tools” restates the emphasis on people vs. rigid processes and dogma. In waterfall projects, IDs often attempt to get as much detail as possible up front, and condense this into lengthy, detailed design documents and specs for approval. There’s nothing wrong with the intent of wanting to get the big picture ahead of things getting built, but there can be a lot wrong in practice, especially if you’re the busy ops guy just handed a fifty page ID design document to sign in blood, with orders from above to make sure its accurate before signing because any changes after signoff will require additional effort and cost.

Rather than both sides, IDs and stakeholders trying to ransom one another with legalese, the next two points in the Manifesto, “We have come to value […] working [instruction] over comprehensive documentation, customer collaboration over contract negotiation” are aimed at getting it right, rather than contingencies when things go wrong.

In agile projects, while the big picture is always present, emphasis on working instruction over design documentation, suggests an agile process for new product development that, loosely based on scrum, might look something like this:

  1. Define high level project goals
  2. IDs have brief, informal discussions with stakeholders and subject matter experts to define and document objectives for discrete, bite sized chunks of instruction, synonymous with midsized learning objectives. Objectives are stored in the backlog, agile jargon for to do list
  3. A limited number of bite sized chunks of instruction are selected from the backlog and built to completion in time boxed iterations, i.e. two weeks
  4. Test, review how the iteration went, repeat from 2

In the example above, usable instruction gets built and tested in small chunks, informing and improving future iterations, eliminating the need for stakeholders to wrack their brains guessing whether or not the fifty pages of specs handed them by well meaning IDs will solve their problem once developed. As an added benefit, this can also remove a lot of legalistic, contract negotiation terror. That is, stakeholders don’t have to worry so much if the design is correct as it can adapt to become correct along the way.

An unfortunate side effect of waterfall processes is that design documents, which become contracts, are helpful when they limit scope creep and other legitimate problems, but unhelpful when they’re used to  ‘protect’ the development effort when reality inconveniently intrudes. “Sorry, but you signed off on it…” fixes nothing when design documents and specs aren’t unfolding as planned in a real world project.

In favoring individuals and interactions over contract negotiation, agile ID lowers the stakes from waterfall’s all in, betting the development effort farm that the the design is sound, to penny ante, making sure the current two week iteration’s worth of work is sound before betting the next two weeks of effort.

This also helps project estimation. IDs and their project managers are often asked to estimate complex projects before design work begins, but extensive design work, which may constitute a large portion of a project, is generally required in order to approach accurate estimates.

In other words, figuring out how long it will take to build instruction for tasks which one doesn’t yet understand, based on frequently marginal documentation, is difficult, but clients are often justifiably reluctant to commit to a project without a clear idea of budget and effort.

Agile methods may not offer a full solution to estimation challenges, but they help. Because agile design and development is iterative, the amount of time required to build the bite sized pieces of a project is less estimate so much as experiment. One figures out how long things will take, not to mention whether they work or not, by building small pieces. It may still take several iterations to get to an accurate estimate of a full project, but at least the client benefits from having usable instruction built as this happens, as opposed to a big, probably shaky design document.

It’s important to note though, that experimental doesn’t mean cavalier, flaky, or figure it out as you go. It means testing design decisions on a small scale, as minimum viable products for those familiar with lean, before committing extensive effort and cost. Those who have sweated the launch of a large waterfall project that has scarcely seen the light of day until launch will appreciate the utility of checking mostly during, rather than mostly after, design and development.

The focus on working instruction also means that small scale failures are valued for their utility in preventing larger failures. While any iteration may end up as all or part cautionary tale as opposed to delivered goods, parts of agile iterations my abe intentionally conducted as experiments, research, or testing. These are termed ‘spikes’ in Scrum, and may be used to answer anything from nuts and bolts technical questions, “will this work on mobile” to serious bottom line questions around ROI, scope, and level of effort: “how much training do they really need?” or “is there ROI in investing in more multimedia?”

Those with significant experience as IDs, stakeholders, or managers probably will have surmised by now that casually dropping the methods discussed above into an organization accustomed to traditional, high stakes, front loaded approaches might be disruptive, regardless of long term benefits. Agile thrives in culturally flatter organizations that value team learning, but  may require shifts in organizational culture at large to implement in more hierarchical, traditional situations.

Implementing agile methods without agile attitudes, or lip service to agile-ish attitudes without practical agile methods tailored to the organization are recipes for failure, making a successful move to agile a potentially challenging change that should be handled skillfully. There’s an awkwardly accurate joke in agile software circles that the more the word “agile” is used, the less so the organization.

Some organizations may be ready for agile ID by nature, by crossover from agile software methods, or by other means. Others may need more guidance for a successful transition. Likewise with individuals, whether openly expressed or not, the potential for freak outs, dragging feet and bruised egos should be taken seriously.

The Agile Manifesto’s conclusion, “While there is value in the items on the right, we value the items on the left more”, affirms that transition to agile if well handled, should be anything but apocalyptic, and is a reminder that the value of past research, experience, systems, and their advocates and practitioners is magnified and enhanced, not diminished. Agile simply adds valuable new layer of tools and methods that can greatly benefit practitioners and stakeholders via potentially lower costs, higher quality, shorter timeframes, and reduced stress for all parties.

Leave a Comment