Planning in Agile Learning Design
The first concept of PODSIR (Plan, Orientate, Design, Select, Iterate, Review) is planning (shown in the blue cycle below). Planning is to ensure the goal or target is identified and that all stakeholders understand the requirements and constraints of the project.
One of the most common mistakes with designing learning processes is failing to link the learning initiative with a business need — the business unit or customer does not understand how the learning and performance solution links to their business needs and/or the designers fail to link a 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 in identifying the correct business linkage is the failure to bring the learners into the planning stage. Rittel (1972) noted that the best experts are often 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 a learning process. Normally you will not be able to bring the entire population of them in, but try to bring in enough learners who will actually represent the population.
The learners are the real stakeholders because they on the ones who have to learn to perform. 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.
Rummler and Brache (1990) reported that their experience was 80% of performance problems reside in the environment, such as processes and resources, while only 20% were training or learning problems. Thus, you need to ensure the problem is really a learning/training problem, not some other performance problem (see NOTE below). However, while many environment problems do require some sort learning/training solution to solve, ensure you get to the root cause.
NOTE: Rummler and Brache 80% environment / 20% training ratio was based on their experience, rather than hard evidence (Christensen, Wallace, 2012).
In addition, Rummler and Brache's 80/20 experience could differ greatly from yours. For example, if the performers have a great deal of autonomy, then you would expect a larger percentage of performance problems to be in the skills and knowledge area (learning solutions), rather than the environment as there is less of a chance that an autonomous performer is restricted by a process or system. Another example is if the performers work in a highly evolving or complex environment that require unique solutions from them, rather than relying on processes, then there is a good chance that a learning or training solution is needed.
Since designers, managers, learners, and perhaps some subject matter experts and/or exemplary performers will be in on the planning stage, 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 groupthink or the Abilene Paradox. You want the team members to disagree and share information. However, their disagreements should be with ideas; not people.
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 as people who sense they have a high status in the group will more likely want to share their knowledge.
As noted earlier, it is best to take an approach that ensures the performance improvement (training, learning process, etc.) ties in with the Business Outcome — the organization's needs, vision, mission, and values. This connects each need with a metric to ensure that it actually does what it is supposed to do. This is best accomplished by linking the Four Levels of Evaluations to the four categories of analysis (Phillips, Phillips, 2002):
- Business Needs are linked to Results (What the organization wants to achieve)
- Job Performance Needs are linked to performance (behavior)
- Training Needs are linked to Learning
- Individual Needs are linked to motivation (reaction)
Linking the four needs with the levels of evaluation shows what questions need to be answered (work from top to bottom) :
In addition to answering the above four questions, the team also needs to decide the minimum requirements for the first iteration. Three major factors come into play for this decision:
- Complexity: The larger the scope of a project, then generally the greater the need to break in down into smaller chunks so that it can more readily managed.
- Customer requirements: What are the minimum needs of the customer and when do they need it?
- Evaluation: If this is a new or complex set of learning processes, then breaking it into small chunks allow you to test each learning process and activity, to see if they will work correctly (see the chapter on iteration)
While I've discussed a few practices to support planning in Agile Learning Design, they can be supplemented by other practices, such as the Analysis phase in ISD or the Seven Management and Planning Tools. . . as long as it support the values and principles of Agile Learning Design. This can best be checked by determining if they fit in the Value and Principles Matrix as shown in the example below:
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 to save the file correctly.
A final point is that planning is not a one-shot affair, but is also iterative, thus it can be returned to on a as needed basis. For example, the next concept, Orientate, will often have to be performed before the initial planning can be initiated and/or once the learning solution is ran through its iterations. Thus, planning is not rigid, but follows the Agile values' of evolutionary and adaptive to ensure customer and learners' needs are met.
This article was first posted on my blog, Planning in Agile Learning Design, but since blogs tend to push posts to the bottom as new posts are created, I thought I would post the series on my web site where they would stay more exposed and could be updated when needed. If you have any comments on this article please feel free to comment on the blog post.
Christensen, B., Wallace, G.W. (2012). Chasing Down the Elusive Credits for Facts and Fictions in Learning and Improvement. eLearn Magazine.
Garnevale, A., Gainer, L., Villet, J. (1990). Training in America: The Organization and Strategic Role of Training. San Francisco: Jossey-Bass.
Phillips, J., Phillips, P. (2002). Reasons Why Training & Development Fails... and What You Can Do About It. Training Magazine, September 2002, pp. 78-85.
Rittel, H. (1972). On the planning crisis: systems analysis of the first and second generation. Bedriftsokonomen, no. 8, pp.390-396.
Rummler, G.A., Brache, A.P. (1990). Improving Performance: How to manage the white space on the organization chart. San Francisco: Jossey-Bass.
Trolley, E. (2006). Lies About Managing the Learning Function, in Lies About Learning. Israelite, L., (ed). Baltimore, Maryland: ASTD.