Agile instructional design

by Jay Cross on February 16, 2009

I’ve been thinking about fresh approaches to instructional design.

Instructional design was invented around the time of World War II. Starting virtually from scratch, America had to train millions of men to be soldiers and millions of civilians to make ships and armaments. The training film was born, soon to be followed with the ADDIE model. ADDIE (analyze, design, develop, implement & evaluate) made it possible to manage the process of creating useful training programs systematically.

Instructional purists still revere the logic of ADDIE. (It’s hard to argue with the concept of planning your work, then working your plan.) but ADDIE is beginning to show its age:

  • Training is only part of the learning equation.
  • Training is generally imposed on people. Whether of not they learn is an entirely different matter. Learning requires motivation. (You can lead a boy to college but you can’t make him think.)
  • ADDIE invariably points to training as the solution. Sometimes it’s more effective to imbed the knowledge in the work than to plant it in the head of the worker.
  • Modern instructional design needs to focus on creating flexible environments that nurture learning rather than rigid programs that attempt to force lessons into the heads of learners.
  • Old-style training enraged many managers because it was separate from work. Why isn’t Sally at work today? Because she’s in training.

It needn’t be this way, particularly since knowledge work and learning are nearly indistinguishable. Most corporate learning today can take place simultaneously with work. A major part of modern instructional design involves creating and nurturing learning ecologies..

Building a learning ecology is a different exercise than building a training program. In lieu of top-down control, it relies on continuous experimentation and evaluation. It takes coordination, flexibility, and on-going conversation. These qualities are at the heart of the discipline of agile programming. Hence, I am exploring how well the principles of agile programming might be incorporated into a new framework for instructional design.


Agile Software Development

This morning I took part in a conference call focused on now might we use the precepts of agile programming in general (non-IT) business settings.

Agile programming has come a long way from its early incarnation as extreme programming on the first wiki. It’s been influenced by lean manufacturing and spawned practices like Scrum.

Yet the agile community remains pretty insular. Only lately have people seriously explored how agile principles and practices might be used outside software development.

Agile Software Development on Wikipedia

Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

The modern definition of agile software development evolved in the mid-1990s as part of a reaction against “heavyweight” methods, perceived to be typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software developers actually perform effective work. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development.

Unlike many design disciplines, Agile’s beginning and principles are easily accessible. See the Agile Software Manifesto, which states:

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.

Another great reference is Martin Fowler’s The New Methodology.

Agile practitioners Jim Benson and Bill Anderson set the stage, outlining the benefits of Agile:

Empirical: learn our capacity
Iterative: small steps get them there
Participatory: client tells what is wanted, feedback is frequent

Discussion flushed out other aspects:

  • John Smith: this is a community of practice approach
  • Great opportunity for people learn by eavesdropping.
  • Makes cost changes conspicuous
  • Introspection along the dimensions of commonly accepted metrics
  • Ability to look back at what we’re capable of
  • The day’s code is not entered in if it doesn’t work
  • Rewards constants communication
  • Daylight overcomes rigid specifications
  • Aesthetics, not practices
  • Teams sharing one terminal learn from one another
  • Relationships among teams is important

Skeptics of agile program don’t believe you can do things one piece at a time; they think you have to eat the whole sausage. Sometimes a company itself has a waterfall style. Scrum and other methodologies call for short, standing, daily meetings; people are skeptical about daily meetings: because they are burned out on traditional meetings.

So….. Do others agree that instructional design would benefit from incorporating the principles of agile?


Comments on this entry are closed.

Previous post:

Next post: