Agile Design: An Ethos for Creating Learning Platforms

Software design and related practices and methods have had a significant influence over the Instructional Design field. For example, ADDIE, Dick and Carey, and Rapid Prototyping are heavily influenced by software development methodologies (Rawsthorne, 2005). Software design methodology is now going through another paradigm shift — Agile Design. And rather than being a methodology, it is more a philosophy or ethos that is best described by its manifesto (Agile Alliance, 2001):

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.

agile learning (instructional) design

The Agile approach recognizes the need for collaboration, faster design solutions, feedback and change for producing business value in our ever faster and more networked society. Thus, for learning professionals to keep pace with the rest of the organization, Agile Design could easily be adapted to fit the needs of the learning and training community by providing an ethos for the design of learning:

We are uncovering better ways of designing
learning processes by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Solutions that promote and speed the development of learning processes over comprehensive documentation
Customer collaboration over contract and formal 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.

Because we still value the items on the right means that we do not have to abandon the technologies that make up our profession, such as ADDIE, 4C/ID, ARCS, Captivate, and PowerPoint. But rather we pull the best concepts from them that will support the values and principles of Agile Design.

Values and Principles of Agile Design

Since Agile is a more of a philosophy, it has values and principles that guide its practices. The Sidky Agile Measurement Index (SAMI), developed by Sidky & Arthur (2008), is probably the most widely used method for guiding Agile principles. It is composed of five values: communication, collaboration, evolutionary, integrated, and encompassing. These five values were heavily inspired by three of Malcolm Gladwell's ideas in The Tipping Point:

  • People = communication & collaboration
  • Message = evolutionary, integrated, & adaptive
  • Suitable environment = all encompassing

Listed below are the five values with their descriptions (please note that I changed the descriptions to fit learning rather than software development):

  • Encompassing: Establishing a vibrant and all-encompassing environment to sustain agility
  • Adaptive: Respond through change through multiple levels of feedback
  • Integrated: Develop high quality learning solutions in and efficient and integrated manner
  • Evolutionary: Deliver learning processes early and continuously
  • Collaborative: Enhance communication and collaboration

The Agile Manifesto basically outlines 12 principles; however, Sidky & Arthur (2008) discovered they could group them into five tight principles (please note that I changed the descriptions to fit learning rather than software development):

  • Embrace change to deliver customer value
  • Plan and deliver learning processes frequently
  • Human centric
  • Technical excellence
  • Collaboration with business people

These five values and principles can be placed in a matrix to guide the selection and population of practices that will best achieve the ethos of Agile Design. The matrix shown below lists the five values in the left column and the five principles in the top row. I then listed some Learning Design practices, concepts, and processes that may be used to guide a performance project. Note that the principles may vary from organization to organization and may even change from project to project within an organization, but any adopted practices should always be guided by the values and principles; that is, they should never go against them:

Agile Design Matrix

So that you don't have to reproduce the above matrix, I am including the Excel file for the Agile matrix of values, principles, and values. The xlsx file is for the latest version of Excel and is the one shown above. The xls file is for older versions of Excel and is the same except the colors are brighter and may need to be toned down:


adaptive to predictive continuum for agile design

These value and principles make Agile more adaptive rather than predictive; and people-oriented rather than process-oriented (Fowler, 2003). It is misleading to view it on the opposite end of a spectrum from "plan-driven" or "disciplined" methods as it implies that agile methods are "unplanned" or "undisciplined." A more accurate distinction is that methods exist on a continuum from "adaptive" to "predictive" and agile methods lie on the "adaptive" side of this continuum (Boehm & Turner, 2004):

To achieve an adaptive and people-oriented process, a strategy is implemented that allows collaboration among the designers, business unit (customer), learners, exemplary performers and/or SMEs, and other interested parties. To accomplish this, a conceptional framework is initiated that allows the strategy to carried out — Plan, Orientate, Design, Select, & Iterate.

Plan, Orientate, Design, Select, & Iterate (PODSI)

  • Plan by identifying the potential target, vision, and feasibility of the project that will ensure the active participation of all stakeholders. Determine if the managers are indeed going to collaborate or are willing to learn to collaborate. If they simply want you to be an order-taker then, "run my friend run, run as fast as you can!" Find a project with people who desire to collaborate.
  • Orientate in order to recognize the level of the complexity of the environment (Cynefin) so that the initial learning architecture can be started to solve the problem. Use Exemplary Performers and/or Subject Matter Experts to help identify the complexity of the environment.
  • Design by using a collaborative approach or model so that only the minimum required knowledge and skills are taught that will resolve the problem. Build other useful benefits into the learning process during the final iterations.
  • Select the correct learning objects, processes, and tools that will provide the needed knowledge and skills that support both formal and informal learning — the use of small learning objects will increase the speed of iterations and allow you to more easily transform parts of the instruction into informal and nonformal learning.
  • Iterate by prototyping the initial design and to determine what other performance support technologies are required that will fully support the learners' quest to better performance. Use After Action Reviews to transform deficiencies into actionable items. Transform the formal learning objects to informal or nonformal learning as possible.
"Failure at an organizational level seems to come from the inability to customize processes and make them their own. Trying to apply someone else's template to your organization directly doesn't work well. It leaves out too many important details of the previous successes and ignores your company's specific situation." — Kent Beck (2006 interview with InfoQ)

PODSI is dynamic in that the above stages are not step-by-step, all encompassing solutions but rather selected concepts from our discipline that best support Agile. Even though they may be performed in order, particularly for the first iteration, the concepts should be thought of more as a network, rather than a flowchart or template. Thus, while the last concept is to iterate the learning process in order to achieve the best solution, the other concepts are also iterated throughout the life-cycle of the project on an as-needed basis.

Essence of Agile Design

Essence of Agile Design


Throughout the upcoming weeks I hope to expand on PODSI, thus I am interested in hearing your feedback, thoughts, and ideas. Please feel free to share, rip, and mix.

Note (December 23, 2009) The compleste series has been posted:


Agile Alliance (2001). Manifesto for Agile Software Development. Retrieved on June 28, 2009 from http://www.agilemanifesto.org/

Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. pp.165-194

Fowler, Martin (2003). The New Methodology. Retrieved on June 28, 2009 from http://www.martinfowler.com/articles/newMethodology.html

Rawsthorne, P. (2005). Agile Methods of Software Engineering should Continue to have an Influence over Instructional Design Methodologies. Cape Breton University & Memorial University of Newfoundland. Retrieved on June 28, 2009 from http://www.rawsthorne.org/bit/docs/RawsthorneAIDFinal.pdf

Sidky, A. & Arthur, J. (2008) Value Driven Agile Adoption: Improving an Organization's Software Development Approach. Fujita, H. & Zualkernan, I. (eds). New Trends in Software Methodologies, Tools and Techniques: Proceedings of the seventh SoMeT_08. Volume 182. Oct 15, 2008. P149-164. The Netherlands: IOS Press. Retrieved Oct 22, 2009: Google Books


jay said...

Don, yes! I am a true believer in new (and agile) approaches to instructional design. See http://bit.ly/l7FHA Glad to see you tackling this one.


leslie said...

"the use of small learning objects will..." This strategy can aid content maintenance --if you have a robust tagging strategy.

I tried to "scrum" a project 5 years ago, but culturally we weren't there yet. Think some agile practices have seeped into asynchronous development, but not as an intentional methodology. Thanks for leading a such thoughtful and useful conversation.

Donald Clark said...

Jay, thank you for the link, I will have to tweet it.

Leslie, yes, unfortunately at times an organization is not ready to move to the next step. While I see the importance in tagging the objects, I see the greater value in using them with Agile, at least in the first few iterations, is that they are easier to work with when you want to change the type of learning or methodology.

Vinod Varma said...

Most significant influence of agile approach in software development, as I see it, is bringing focus back, from excessive documentation in the name of process and engineering, into delivering business value with honest communication and teamwork. I believe adoption of agile approach would help eLearning space as well, bringing focus back into business considerations especially given diverse, sometimes conflicting interests, of stakeholders of eLearning space

Bob MacNeal said...

It took me bit to get the point of the matrix. Once I figured it out, I think it would be a useful discussion starter for an agile coach in a cultural assessment phase. It would be interesting to contrast the responses you got from developers vs the responses you got from management.

Donald Clark said...

Bob, yes the matrix is a little confusing. I think part of it is because it does not leave a lot of room for explaining the practices. In the coming posts I will try to explain a few practices that fit well with the values and principles would should help to clear it up more.

nayan said...

don, you are my touchstone.
when i need to find something i always go to your site and am never let down.
i do not know much abuot agile, however i totally sign up to what you are saying about learning and currently have experienced it in my work space. and find that we have followed the five priciples to the T, and have experienced great collaboration

David said...

Great post.

I've been thinking about a similar move towards agile design. But more in the context of a central group charged with helping university academics improve their L&T. e.g. http://davidtjones.wordpress.com/2008/05/18/understanding-approaches-to-improving-a-course/

Like the in-depth approach you've taken in drawing on the philosophy/theory underlying agile development. There's a surprising amount of this out there.

e.g. http://davidtjones.wordpress.com/2009/05/25/teleological-and-ateleological-processes/

Look forward to seeing more.

Donald Clark said...

I have already posted the complete series:

Post 1 - Agile Design: An Ethos for Creating Learning Platforms

Post 2 - Planning in Agile Learning Design

Post 3 - Orientation in Agile Learning Design

Post 4 - Designing Agile Learning

Post 5 - Selection in Agile Learning Design

Post 6 - Agile Learning Design: Tools for Learners

Post 7 - Iterations in Agile Learning Design

Post 8 - Periodic Table of Agile Learning

Lisa Powers said...

I'm just starting out in the instructional design arena, but I am a proponent of the Agile approach in the software development world. I was heaving involved in early 2000's on creating an adopting an "agile methodology" for my company. It is definitely a better way to produce software and I can see the parallel's for ID. Really anxious to get started on this--

Anonymous said...

A good starting point, but I do find it to be missing two of the key elements that turned out to be critical in the Agile software dev community (things we learned since 2009).

First, focus on technical excellence - raw ability to ship things without screwing up other things - was at a nadir in 2008. This resulted in a large number of Agile transitions (since ability to ship was the previous bottleneck), but a large number of failures.

I suspect (but don't know, having only read your analysis & not put it into practice a few dozen times) that you are similarly missing stuff in this area. In particular, the role of refactoring, emergent design, continuous re-design, risk reduction, and all that stuff (what we now call 2-star agile (agilefluency.com)).

Second, 2008/9 was the high water mark of "Chinese menu" agile. Teams were encouraged, via quotes like Kent Beck's, to modify Agile for their context. We had learned that one size did not fit all.

Unfortunately, it was to be another couple of years before we learned that everyone heard that advice and followed it by modifying Agile for their context before they ever tried Agile. The result was a large number of Agile practices that were missing key elements of success.

This worked when the modification was done by an experienced Agile coach, but transitions were just starting to be done without any coaches. Those two things happening simultaneously was...a problem. So current advice is to do it by the book for at least 3 months before changing anything, and then to immediately start modifying it to your context. Yes, the team will need to modify it to work for them, but they will need to first do it by the book in order to understand the interactions enough to safely modify it.

If your approach works, then I recommend offering the same semi-prescriptive advice. Do it a known-good way for a quarter, then start experimenting.