Big Dog, Little Dog: Planning in Agile Learning Design

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

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

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.

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:

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:

For example, I took the main points (practices) of this post and inserted them into the Value and Principles 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.