Orientation in Agile Learning Design

This is the third in a series of posts on Agile Learning Design:

• Post 1 - Agile Design: An Ethos for Creating Learning Platforms.
• Post 2 - Planning in Agile Learning Design

The second concept of PODSI (Plan, Orientate, Design, Select, & Iterate) is Orientating to ensure you understand the contextual issues of the environment you will be designing in.

In the early 70's, three similar, but different, concepts emerged on the importance of orientation and learning — Boyd's OODA Loop, Double Loop Learning, and After Action Reviews.

Col. John Boyd, USAF, developed the OODA Loop for decision-making in a combat environment, particularly for combat pilots, and is now used in many organizations. He viewed problems as a cycle of Observation, Orientation, Decision, and Action, (OODA) and determined that whoever could cycle through the loop the fastest would win in a combat fight.

Boyd realized that people normally performed three of the decision-making tasks — observing, decision, and then performing an action, perhaps without really thinking about it, but one of their biggest weakness was failing to orientate themselves to the environment; thus he spent most of his time talking about it. This is why he highlighted "Orientation" in his diagram.

Chris Argyris coined the term "Double Loop Learning" and "Single Loop Learning. Single loop learning has often been compared to a thermostat in that it makes a "decision" to either turn on or off. Double loop learning is like a thermostat that asks "why" — Is this a good time to switch settings? Are there people in here? Are they in bed? Are they dressed for a colder setting? — thus it orientates itself to the present environment in order to make the wisest decision.

A person who is double loop learning is basically "orientating" herself to all possible solutions within her environment by asking a series of "whys" that is similar to Sakichi Toyoda's (the founder of Toyota) method who used a technique he called the Five Whys — when confronted with a problem you ask "why" five times. By the time the fifth why is answered, you should be at the root cause of the problem.

Amusing, but informative video on double and single loop learning (6.21 minutes):

 

Before the early 70's the U.S. Army used Performance Critiques to determine the effectiveness of training (mostly war games), which in a nutshell determined who won and who lost. Deciding that this was not the best way to get their money's worth they came up with the After Action Review (AAR):

The U.S. Army's did a slight twist on orientating oneself in that after a learning event, there is still more to learn by re-orientating oneself to the past and then asking a lot of whys so that new learnings are created — one prepares for the future by learning from the past. Learning is transformed from an event to a process by discovering "lessons learned."

Differences between a Performance Critique and an AAR:

Orientation in the Agile Design Environment

With all this emphasis on orientation you would think that by now we would have it down pat, but the truth is that people do not spend enough time on it, thus solutions continue to miss their intended mark. To aid us in orientating ourselves to the proper level of complexity so that the initial learning architecture can be designed, we will use the Cynefin (pronounced cunevin) framework.

The Cynefin framework was created by Dave Snowden and coworkers at IBM's Institute of Knowledge Management and consists of five domains:

• Simple - the relationship between cause and effect is obvious to all; the approach is to Sense - Categorize - Respond by applying best practices.
• Complicated - the relationship between cause and effect requires analysis or some other form of investigation and the application of expert knowledge; the approach is to Sense - Analyze - Respond by discovering patterns and then apply good practice.
• Complex - the relationship between cause and effect can only be perceived in retrospect, but not in advance; the approach is to Probe - Sense - Respond by sensing emergent practice, such as telling stories (narratives), which is similar to an AAR.
• Chaotic - there is no relationship between cause and effect at systems level; the approach is to Act - Sense - Respond to discover novel practice (take action) in order push the environment into one of the other domains so further action can take place.
• Disorder - the state of not knowing what type of causality exists, thus people will revert to their own comfort zone when making decisions.

In this short video, Shawn Callahan of Anecdote gives a very good explanation of the Cynefin or Complexity model:

While gaining a full understanding of Cynefin framework requires a fairly extensive workshop, there are a few simple techniques that will help to identify the complexity of an Agile Design environment. However, to do so we need to tightly define three terms: subject matter expert, exemplary performer, and expert performer.

Subject Matter Expert (SME): Knows the subject or task, but does not presently perform in that area. An example is a college professor that teaches business, but is not engaged in a business; or a person that has performed in the subject area in the past in a wide variety of contexts, but is not presently a performer in that area.

Exemplary performer: Is able to perform the tasks for a certain subject area and is worthy of imitation, but does not have a great deal of knowledge about the peripherals surrounding the subject or task.

Expert performer: Is able to perform the tasks for a certain subject area and is worthy of imitation; in addition they have a great deal of knowledge about the peripherals surrounding the subject or task. An example might be a physician assistant (PA) who works in that job during the day and teaches college courses about it at night or a PA who not only performs the duties, but has performed in a number of surrounding areas that gives him a broad context of the subject and tasks. Basically an expert performer is both a SME and Exemplary Performer.

These definitions of the various "experts" that learning/instructional designers call upon are keys for identifying the complexity of the design environment:

Simple

In a simple design environment someone on the team has identified one or more Exemplary Performers who will be the role model(s) for the learning being designed. For example, a manager comes to you who wants to train her people to perform in the same manner as an Exemplary Performer she has identified; or during your research you identify a few Exemplary Performers who will make perfect role models.

While this is normally one of the easier learning platforms to design, it does have a couple of pitfalls. The first is thinking that since it is fairly easy to design, it is also easy to learn and perform, thus the failing to build enough practice time into the learning platform. Designers often become so absorbed in their work that they fail to realize how much time they are putting into it, thus they spend a couple of weeks working on the task, then think they can transform it into a two-hour information dump.

The second pitfall is failing to support the informal learning that must occur after the formal learning. There is an average of an 1:4 ratio in which one hour of formal learning produces four hours of informal learning. Thus support for the informal learning is also required to transform a training event into a learning process — the U.S. Army helped with this by giving us the concepts used in an AAR.

Formal learning is a seed that produces a lot of informal learning. If you don't plant the seed, you don't get the fruit. If you don't nourish the plant (informal learning), you end up getting underdeveloped fruit.

Note that the two pitfalls are not limited to a Simple environment, in that they can also occur within any of the other environments. However, in a Simple environment you will probably be more concerned with practicing within the formal learning environment than within an informal learning environment.

Complicated

In a Complicated design environment someone on the team will identify one or more Expert Performers whose skills (exemplary performance) and knowledge of the surrounding tasks and subject matter can be combined and/or transformed to form a "good enough" practice. The idea here is to take the "best" practices of their exemplary skills and subject matter expertise, along with the input of others, and combine them into a workable performance solution. In addition, you are going to start relying on the learners or affected (those who are going to be most affected by the learning solution) more as the problems are going to be slightly more wicked than within a Simple environment.

Like the simple environment, you will have to watch for the two pitfalls; however, in this Complicated learning environment you will probably have to pay about equal attention to both the formal and informal learnings of the learners/performers, in addition to relying on more iterations to ensure you get the feedback of the affected.

Complex

In a Complex learning design environment there are few or no exemplary performance examples to draw upon, thus you rely mainly upon subject matter experts (SMEs) and others to try to draw a picture of an "emergent" practice. However, some, if not most of the SMEs, should come from the environment (those affected) as they are probably the best "experts" of that environment.

While the initial learning platform might start out with more formal learning than informal learning, you need to look for solutions during the design and iterations to support informal learning while lessening the need for formal learning. This is because the complexity of the environment normally only requires a small seed of formal learning but needs extra nourishments of informal learning.

Chaotic

In a Chaotic learning design environment the initial solutions will come mostly through the managers and affected/learners. While the approach is to Act - Sense - Respond, it will more than likely require several iterations, rather than a one time shot. After each iteration, reexamine the environment to see if it has dropped to a lower level, more than likely a Complex environment, then take the appropriate approach.

We look at the present through a rear-view mirror. We march backwards into the future. - Marshall McLuhan

While you will often look to the past to predict the future, entering a chaotic environment is often uncharted territory, thus you will need an intense amount of collaboration to create unique solutions so that you do not harm your customers and the workers/learners with a poorly implemented solution.

Disorder

If by chance you discover you are in a Disorder environment where no one is sure of the environment, then more collaboration is called for with perhaps a few more "experts" (mostly the learners). Remaining in this state is unacceptable.

Agile Matrix for Orientation

I took the main points (practices) of this post and inserted them into the Value and Principles Matrix (See first post on Agile Design for Learning) to show how orientation fits into the values and principles of Agile Design:

• Download Excel Matrix file for Orientation (xls version): Agile_Matrix4.xls
• Download Excel Matrix file for Orientation (xlsx version): Agile_Matrix4.xlsx

Note On some systems the xlsx version will try to download as a zip file. In that case, click the above xlsx file with the right mouse button to bring up the context menu and then click "Save Target As..." item. When the dialog window opens, change the extension from .zip to .xlsx — this will save the file correctly.