11.19.2009

Designing for Agile Learning

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

Ban Clippy

The third concept of PODSI (Plan, Orientate, Design, Select, & Iterate) is Learning Design to facilitate interactions between humans and content in order to increase performance. It accomplishes "interactions" through the use of "awareness" that not only allows the content to sense and respond to the learners, such as feedback and guiding them to their next learning need; but also allowing the learners to sense and respond to the content; and as was noted during a Twitter conversation (with @usable learning and @Kathysierra), "the awareness should be more like Amazon's Lists rather than Clippy." Note that the definition is based somewhat on Safer's (2007) definition of interaction design.

The Texture of Wine

Agile Design captures the texture & nuance of learning

Almost anyone can produce content but it takes a good Learning Designer to add awareness. It is also contextual in that it facilitates specific performance problems under a specific set of circumstances — my solution may not work for a similar problem. The end goal is to produce adaptive, agile thinkers, competent to perform within a dynamic working environment (Mark ley, 2006). While Learning Design is mostly art, it does has best practices.

Learning Design does not align itself with any one medium or technology, rather it is only concerned with the correct technology that aids in the learning/performance solution. Thus, it might be compared to distributed Learning (dL) that relies primarily on indirect communication between learners and instructors that allows the learners to learn at different times, at their own pace, as well as in different places. The old way of spelling the acronym was "DL", however this emphasized delivery method and learning equally, thus the correct acronym is now "dL", which emphasizes Learning without focus on delivery (Markley, 2006). That is, it uses face-to-face instruction when it makes sense.

Techniques to Learning Design

While there are specific methodologies for creating learning or instructional design, such as ISD, ADDIE, and van Merriënboer's 4C/ID Model; there are four design lenses or techniques that provide a means for viewing the overall structure of a specific learning design:

1. Performance-Centered Design

Focuses on the tasks that are composed of actions and decisions that the learners need to perform. A Learning Designer uses an Exemplary Performer as a model and then they build the instructional content and add awareness to it.

2. Guru Design

Focuses on the skills and knowledge of experts (SMEs), in which the designer may or may not be the guru. A Learning Designer uses one or more SMEs as knowledge sources and then they build the instructional content and add awareness to it.

3. Learner-Centered Design

Focuses on the needs and goals of the learners who guide the design; while the Learning Designer aids with the content and awareness. This is somewhat similar to user-centered design that is based on the concept that the people who use a product or service know what their needs, preferences, and goals are, thus they and the Learning Designer collaborate throughout every stage of the Agile Design process to build the content and awareness. It should be noted that the vast majority of so called "Learner-Centered Designs" out there are based on the other three design techniques because they are focused on what others thought the needs and goals of the learners should be, not what the learners thought they should be.

4. System Design

System Design focuses on the system's inputs, outputs, processes, feedback loops, goals, etc. to guide the design.

Specialty Designs (subset)

This includes ISD or ADDIE, which is basically a combination of Performance, Guru, and System Design, but normally little or no Learner-Centered Design (not because the model won't let you, but because the designers fail to). It also includes the micro-instructional designs, such a van Merriënboer's 4C/ID Model that focuses on task specific skills.

"The answer is, there's an infinite number of answers." - Amanda Palmer of the Dresden Dolls

Almost no Learning Design project is accomplished through just one of the four approaches or subsets, but is normally a mixture of them, with one of them being the primary approach to design. For example, a Learner-Centered Design might perform System Design and call on experts or gurus to help with the design; while a Performance Design might include some System Design, in addition to using Merriënboer's 4C/ID for some specialty tasks.

Plug and Play with ISD

So just as you can "plug and play" different tools or methods into ISD, you also plug these tools into an Agile Learning Design so that rather than working with a tool box that only contains a hammer, you work with a full set of tools that compliments the learning platform in order to fast-track and retain learning.

Learning Design Approaches & Orientation

The source of where you get the content (Exemplary Performers, Expert Performers, SMEs, and/or Learners/Performers) as discussed in the last post clues you to the level of complexity of the design environment, which in turn tells you the primary design approach:

  • Exemplary Performers → Simple Environment → Performance-Centered Design
  • Expert Performers → Complicated Environment → Guru Design
  • SMEs & Learners/Performers → Complex Environment → Learner-Centered Design
  • Learners/Performers & managers → Chaotic Environment → System Design

Or which could be pictured as:

Complexity and Design

Click to enlarge

Being able to locate the correct level of complexity of the environment tells you the main design approach to take:

Simple Design Environment - SCR

Sense by using a collaborative process to create shared awareness and understanding of each team member's perspectives in order to create a mental model of the learning problem so that the correct decision-making can be performed.

You know you are in a simple learning design environment when you have Exemplary Performers who role model the required performance while you observe and categorize into tasks, skills, knowledge, and performance steps.

You respond by applying best practices such as creating learning objectives through a series of If/Then statements:

If we want to increase sales of our new service, then the sales representatives need to be able to perform an effective sales presentation. If we want them to perform the presentation, then they need to learn these skills __________, __________, and __________ (skills are categorized by observing the Exemplary Performers role modeling). If they need to perform these skills, then they will require this knowledge __________, __________, and __________ (knowledge is categorized by interviewing the Exemplary Performers role modeling).

This series of If/Then statements can also be visualized by using Performance or Action mapping as Catchy Moore shows in this slide presentation:

Complicated Design Environment - SAR

Sense by using a collaborative process to create shared awareness and understanding of each team member's perspectives in order to create a mental model of the learning problem so that the correct decision-making can be made.

A complicated learning design environment is similar to a simple learning design environment except rather than having Exemplary Performers who you observe, you have SMEs (Subject Matter Experts), who you interview and ask questions in order to analyze their responses.

You then respond by discovering patterns in their responses and transforming the information into good practices. And normally the only way to determine if it is indeed a "good practice" is through a series of iterations. Thus while a simple environment will only require a few iterations, a complicated environment will require several more.

Complex Design Environment - PSR

Since there are no Exemplary Performers to observe or SMEs to interview, the relationship between cause and effect can only be perceived in retrospect, thus the approach is to probe through deep collaboration among the learners, managers, and designers, such as telling stories about what they are experiencing (narratives). It is often helpful to look at the system and processes by starting with the output and working backwards through them in order see what to discuss (collaborate) and if it will help with the solution. Thus the primary design approach is Learner-Centered with the learners fulfilling the roles of SMEs, with perhaps some System Design added in. In addition, you can use a processes similar to the method Joe Deegan describes in his blog post, Project Based Learning in 3 Steps.

This probing effect should start to paint a picture or pattern that allows you to sense an "emergent practice" that can be responded to by designing and then implementing a solution based on the observed pattern. Since this will be a new practice, it will more than likely have to go though several rounds of iterations to arrive at the "emergent" practice.

Chaotic Design Environment - ASR

Since there is no relationship between cause and effect that the team (learners, managers, and designers) can agree upon, you will need to look at the system and processes by starting with the output and working backwards in order see what you can act upon. This might seem similar to a Complex Environment, but with a Chaotic Environment you are basically taking guesses of what to do (perhaps educated ones), while with a Complex Environment you are seeing patterns and getting an "Aha! moment" — this will work.

Once the change has been implemented, sense the environment again and see if the team can now agree upon the correct level of complexity. If not repeat the process with a new "act" until an agreement can be made.

By forcing changes into the chaotic environment you eventually push it into one of the other three domains. At this point a pattern should emerge that will allow the team to correctly identify the environment (more than likely a Complex Environment), thus you can now respond with one of the above three approaches.

The Complexity of Design Approaches

Knowing which design environment you are in helps with the planning by, 1) informing you of the number of design approaches that will be involved, and 2) estimating the number of iterations that will be needed.

1. As the level of complexity increases, the number of design approaches to solve the problem correspondly increases; however, there will normally be one major design approach. This will give you an idea of the scope of the design solution that you will be working in:

Complexity and Design Approaches

2. As the level of complexity increases, the number of iterations to reach a "good-enough" level correspondly increases. This will give you an idea of the number of iterations that will be needed:

Complexity and Interations

Up Next

The design concept creates the basic plan for carrying out the Selection and development of learning objects for a dL platform, which will be covered in the next post. And while selection might seem rather mundane at first, it's more or less the heart of Agile Design.

References

Markley, J., 2006. The Army Distributed Learning Program. Training and Doctrine Command (TRADOC): presentation given at the U.S. Army Courseware Conference March, 14, 2006. Retrieved No, 2, 2009: http://wow.tradoc.army.mil/tadlp/presentations/dlcwconf06.pp3

11.10.2009

Orientation in Agile Learning Design

This is the third in a series of posts on 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.

Learning through orientation

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.

Boyd's OODA Loop

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.

Double Loop Learning

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):

 

After Action Reviews

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:

Increase learning

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:

Cynefin Framework
  • 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

blank matrix

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:

Agile Orientate Matrix

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.

11.03.2009

Planning in Agile Learning Design

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

The first concept of PODSI (Plan, Orientate, Design, Select, & Iterate) is planning to ensure the goal or target is identified and that all stakeholders see the feasibility of the project. One of the most common mistakes with designing learning processes is failing to link the learning platform with a business need — the business unit or customer does not understand how the performance solution links to their business needs and/or the designers fail to link the correct solution to a real business need.

Network all stakeholeds in agile design

Business linkage is a "high value add" that is defined as the difference-making in business because it adds high value (Garnevale, Gainer, & Villet, 1990). Yet, defining how our learning processes and platforms link to other business units is one of the activities that we normally spend the least amount of time on (Trolley, 2006). One way to understand your customers' need is to determine how they will evaluate the effectiveness of the learning solution before you begin the project, not after.

Another impediment to identifying the correct business linkage is the failure to bring the learners into the planning stage. Rittel (1972) noted that often the best experts with the best knowledge for solving wicked problems are those affected by the solution; in this case it is the learners themselves. Yet, the only time we normally bring them in is to be guinea pigs for testing our learning process. Now normally you will not be able do bring the entire population of them in, but do bring in enough learners that will actual represent the population.

The learners are the real stakeholders, thus even if you or the managers don't agree as to what they are saying, you need to listen, guide, and act on their needs and perspectives so that they take ownership of the learning and performance solution. This is one way they gain metalearning and metacognitive skills.

In addition, Rummler and Brache's experience was that 80% of performance problems reside in the environment, such as processes and systems, so ensure the problem is really a learning/training problem, not some other performance problem; while most of these problems do require some sort of learning solution, ensure you get to the root cause.

Note that Rummler and Brache's 80% rule could differ greatly from yours; if the performers/learners have a great deal of autonomy, then you would expect a larger percentage of performance problems will be in the skills and knowledge area (learning solutions), rather than the environment (other performance solutions) as there is less of a chance that an autonomous performer is restricted by a process or system. Another reason is if the performers/learners work in a highly evolving or complex environment that require unique solutions from them, rather than relying on a process that leads them to a preplanned solution.

Since designers, managers, learners, and perhaps some subject matter experts and/or exemplary performers will be in on the planning, a high degree of collaboration needs to take place to accurately identify the problem and solution. Collaboration does not mean agreeing with everything others say as this leads to group-think or the Abilene Paradox. You want the team members to disagree and share information. To encourage lower status members to share, which may often be the learners, the members' expertise needs to be acknowledged to the group at the onset of the planning stage — people who sense they have a high status in the group will more likely want to share their knowledge.

Note that by arguing, we mean focusing on the problems, not crass behavior; telling narratives, not finger-pointing; and finding solutions that benefit the organization, not trying to force one's agenda. No matter how complex or argumentative an issue is, it can normally be broken down to three basic artifacts:

  • Questions
  • Ideas
  • Arguments (pros and cons)

Paul Culmsee tells a great story about using these artifacts to guide the discussion and collaboration in a blog post.

One of the tools for capturing the ideas during planning is a concept or mind map. While Paul's story uses Compendium (free), just about any mind mapping tool will work; however, Compendium was built especially for this type of collaboration in order to show different viewpoints, positions, and pros and cons organized by using logical connections:

Compendium screen shot

For other tools that will aid the collaboration process, see McKinsey & Company's Using technology to improve workforce collaboration. In addition, the article includes a neat Flash based collaboration types and tools app that shows day-to-day activities with various technologies that promote work and learning flows.

Since this is an "agile" environment, we have to ensure that all the individuals are able to interact in a manner so that everyone understands the goal or target that needs to be met — exactly what change of performance will occur after the learners return to their jobs and how that change benefits not only the business unit, but the entire organization as well.

While I've given a few practices to support planning in Agile Design in this post, they can be supplemented by other practices, such as the Analysis phase in ISD, as long as they support the values and principles of Agile Design. This can best be checked by determining if they fit in the Value and Principles Matrix:

blank matrix

For example, I took the main points (practices) of this post and inserted them into the Value and Principles Matrix:

Agile Planning Matrix

Download Excel Value and Principles Matrix file: Agile_Planning_Matrix.xls
Download Excel Value and Principles Matrix file: Agile_Planning_Matrix.xlsx

A final point is that planning is not a one-shot affair, but is iterative, thus it can be returned to on a as needed basis. For example, the next concept, Orientate (which will be covered in the next post), will often have to be performed before the initial planning can be initiated and/or once the learning solution is ran thru its iterations. Thus planning is not rigid, but follows the Agile values' of evolutionary and adaptive to ensure customer and learners' needs are met.

References

Garnevale, A., Gainer, L., & Villet, J., (1990), Training in America: The Organization and Strategic Role of Training. San Francisco: Jossey-Bass.

Rittel, H. (1972). On the planning crisis: systems analysis of the "first and second generation.Bedriftsokonomen. No. 8, pp.390-396.

Trolley, E. (2006). Lies About Learning. Larry Israelite, ed. Baltimore, Maryland: ASTD.

10.26.2009

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

Thoughts?

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.

References

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

10.21.2009

The Brick & Mortar Mix of Learning

In his blog, Jay Cross points to relative old, but interesting article on informal learning: Informal Learning and the Transfer of Learning: How Managers Develop Proficiency and notes, "If you're still relying on formal training to develop managers, you might want to give this one a read."

The paper is more interesting for what it omits, rather than what it purpose seems to be. That is, it seems to tout the importance of informal learning, rather than from what I see is the real key finding — its the mix that matters. For example, it makes several comments along these lines:

"Because skills learned informally are likely to share similar features with transfer tasks in terms of context and content, the potential exists for skills learned informally to be more readily transferred than skills learned in formal training contexts."
"Our study suggested that managers learn mostly from informal learning, that proficiency is the product of informal learning, and that metacognitive knowledge and self-regulation skills moderate informal learning and the transfer process.

In the paper they show the following chart (p377):

When referring to the chart they note, "The distribution indicates that managers reported learning all twenty skills predominantly from informal learning activities." Yes, while the managers believed they learnt more from informal learning, the chart actually seems to be showing that they learn a core base from formal instruction, and then they build from their proficiency from there. In addition, some core skills only need a drop of formal learning to get the process going, while others require a heavy dose.

This goes back to the previous post in which I noted that some learning episodes that are strictly informal may be too narrowly based in that the learner only learns part of a task or superficial skills that may not be transferable to the job (Bell and Dale 1999).

Thus, just as we have a "blend" of learning media and processes, we also need the proper mix of formal and informal learning. This means you not only have to select the proper blend of formal learning, but also select the proper mix of formal and informal learning. In turn, you then have to select the best blend of informal learning that will help the learners transfer their skills to the job.

In the paper they mention a study in which pilots with more flight experience perform better on a simulated flight test (that is, a transfer task) than did their novice counterparts. Now I don't believe that anyone is going to argue this point, but the other part to it is that those better performing pilots would have never been able to perform in the first place if it was not for their core skills gained with formal learning.

In the comment section on my previous post Michael Hanley notes, "...the reality is that all of these exist on a 'learning continuum.'" This learning continuum is also the subject of a post by Clark Quinn: The Formal/Informal Continuum.

Thus, its not a matter of designing learning from one side of the continuum or the other because you need the core skills from one side and the proficiency of actually being able to put those skills into practice from the other side. In addition you need that mix from the middle that is not readily identifiable as either formal or informal.