Are You Ready for Agile Learning Design?

The twin constraints that we encountered in the Agile@IBM project—ever-changing requirements and short delivery schedules—are becoming increasingly common. At IBM, our frequent focus on technology topics decreases the shelf life of our learning content. Then, as learning content changes, so does our roster of content experts.

Meanwhile, IBM’s acquisitions strategy and geo-expansion strategy have created changes in the makeup of our workforce as well as in the culture-based expectations of our learners. We also are finding that we need to deliver learning in countries with technology infrastructure obstacles; in many cases our usual learning delivery platforms will be unusable in those locations for the foreseeable future. Finally, we operate in a highly competitive environment in which our immediate business goals are in a state of constant change.

It is not only learning design and technology that are changing; the learning experience itself is changing as well. Our learners used to be called away from their desks to participate in formal training sessions. Now they require work-embedded, social, and informal learning delivered at the point of need in a variety of flexible platforms to accommodate their travel schedules and time zone differences. Our learners are being asked to be as flexible in their learning habits as they are in their work habits. Many of them are feeling the loss of classic face-to-face learning events.

Ultimately, our role as learning designers is changing. Many of us who used to work alongside content experts to create self-paced instruction now find ourselves working with the learners themselves to co-create learning experiences. We also are finding that our stakeholders are becoming more involved in the design process and are expecting more flexibility from us.

Delivering module after module of e-learning is no longer sufficient. It is as though we once built trains, and now we design access to trains by designing a track architecture. As we look at the trains speeding along the tracks and wonder at the growing infrastructure, we realize that we find it difficult to predict what will be asked of us in the future.

Like others in our profession, we have been taught and certified in the classic ADDIE method (analyze, design, develop, implement, and evaluate, performed in sequence) to produce the learning needed to enable our workforce. We successfully have leveraged models published by Robert Branson at Florida State University and the U.S. Army, among others. Using ADDIE, we have designed and delivered decades’ worth of effective learning initiatives.

However, we no longer can apply ADDIE in the sequential manner that we once did. We cannot afford to complete our analysis before moving to design, and then create fully detailed design documents before showing them to stakeholders. As a result, we found ourselves applying the stages of ADDIE, originally a sequential process, in a somewhat more incremental, iterative manner. For instance, tasks normally associated with the development phase may be executed before design is complete, provided that team members work in close collaboration with one another, their clients, and users.

We have come to view the five phases of ADDIE as both the backbone and the common language of our work. However, ADDIE by itself is not enabling the rapid response that we need now. Although we see no reason to reject ADDIE and any of the benefits it can bring us, we must acknowledge that ADDIE “classic” is no longer enough. We need to be more nimble, flexible, and lean. We need to be more Agile.

The term Agile is often described as a systems engineering method. Yet when we dig deeper we find Agile to be an overarching collection of practices influenced by many disciplines.

• From software engineering, Agile inherits Extreme Programming and its practices enabling business leaders and software developers to work together to determine and attain shared, realistic goals.
• From both systems and software engineering, Agile borrows the Rational Unified Process and its iterative development methodology, which delivers useful output every few weeks.
• From manufacturing, Agile gains Lean’s emphasis on the elimination of waste.
• From product development, Agile inherits short, daily “scrum” update meetings that facilitate collaboration and keep teams focused on their incremental deliverables.

You may be asking how this might be applied to learning design. At IBM, Agile adapts well to additional domains, including that of corporate learning. Currently, Agile is used by IBM instructional design teams to:

• enable us to adapt to changing requirements
• reduce risk to our projects
• increase visibility of our projects’ progress
• involve stakeholders and learners from the beginning of the project onward
• accelerate the value we bring to our business.

If you are interested in pursuing Agile Learning Design, you will want to follow one or more of these Agile key practices, described here through an instructional design lens.

Emphasize individuals and interactions over processes and tools. With Agile, the team is all important. It is self-directed and regularly examines its own performance and seeks opportunities to streamline. Short, daily scrum meetings enable team members to share status and assist each other in timely fashion. IBM has found that scrum meetings significantly decreased time to delivery for our leadership development programs.

Process is regarded with a healthy degree of suspicion because it is associated with overhead and project bloat. At IBM, project managers and team leaders are provided with an Agile learning curriculum as part of their certification requirements so they can help accelerate adoption of Lean methodology rather than retard it.

Tools that are intuitive and quickly deployed are generally preferred. Rapid prototyping finds itself right at home with Agile. When we were tasked with creating a common design for multiple interactive websites, each on a different topic related to software products and services, we found rapid prototyping to be indispensable because it enabled us to lead discussion within an unusually large and diverse group of stakeholders. Tools used in rapid prototyping need not be expensive or difficult to master; even PowerPoint and Microsoft Paint can be used effectively.

Emphasize usable deliverables over comprehensive documentation. In the past, every day spent designing and developing learning was a day that employees went without the benefit of that learning. With Agile, our emphasis is on enabling employees to learn immediately and leveraging their experiences to drive improvements into the continuously improving overall learning experience. Rather than developing module after module of formal self-paced instruction, we emphasize providing access to content and designing learning experiences that use wikis, blogs, forums, surveys, and dashboards.

Iterative development, an Agile hallmark, helps learning teams begin to drive organizational change right away. Iterations usually last between two and four weeks apiece. By definition, each iteration finishes on schedule and results in the completion of a usable deliverable. Emphasis is on deliverables that are used by the learners themselves. Iteration has been indispensable in the Succeeding@IBM program for new employees because it has allowed us to enable our workforce amidst the constant churn of new hiring and acquisitions.

Documents and other artifacts are kept small in number and in size. Most are either of a throwaway nature, as is the case with rapid prototyping, or are living documents, as is the case of backlogs (high-level prioritized requirements lists) and “burndown” charts (lists of tasks completed each day).

Emphasize collaboration over negotiation. Agile brings stakeholders into the project as fully embedded team members, ensuring they have continuous input in the project as well as in-depth knowledge of its progress. The media specialists, programmers, and educational specialists comprising the learning design team meet regularly with stakeholders from the earliest design discussions and prototypes. Negotiation over “how it should be” versus “how this functions today” is considered waste.

The learners themselves are viewed as stakeholders. The use-of-user stories (sometimes positioned as “use cases”) enable a team to view the entire project from the point of view of a typical learner right from the start. Throughout the project, iterative releases combined with feedback avenues enable a trial-and-error approach. As we found with our Cloud Solution Workshop, the result is a significant reduction in risk to the project.

Emphasize responding to change over adhering to a plan. Those new to Agile often are surprised that changing requirements are welcomed, even late in a project. Rather than rein in change, Agile projects harness it to competitive advantage. Short iterations; lightweight processes, tooling, and documentation; and early and continuous feedback from business leaders and learners all work together to ensure that learning teams don’t fall behind the change curve.

Problems that no longer exist or are no longer important are easily tossed aside. Learners become confident that returning to our sites will expose them to fresh content and an improved learning experience. Perhaps most surprisingly, learning designers and developers find that they are able to maintain a comfortable, constant pace because they are not tethered to long release cycles and unexpected demands. Quick response to changing conditions is at the heart of Agile.

When we began the Agile@IBM initiative, we were new to the idea of Agile Learning Design. Nevertheless, we were able to successfully manage iterative design and development cycles, integrate our stakeholders and users from the start, and use their feedback and involvement to refine not only our solutions but sometimes the work processes themselves.

By applying Agile practices, we managed to roll out an extensive set of successful learning solutions. We began with a workshop for software development teams, then added workshops for project managers and team leaders. To promote inter-team collaboration, we deployed town halls, learning “suites” that gathered blended learning, a community of practice, and shared stories about best practices and lessons learned from real software projects.

We created video lectures for those who couldn’t attend the face-to-face workshops. Also, live virtual classroom meetings enabled some software developers who are globally dispersed to work together on particular areas for improvement. The team also implemented a performance monitoring dashboard to track progress in the adoption of Agile practices as we moved toward our intended end state.

We found that social learning techniques work hand in hand with the Agile approach. Social software is enabling users to learn from peers who are applying the learning themselves, as well as from experts who are eager to distribute their knowledge to as many people as possible. This close collaboration brings realistic, workable, and current solutions directly to the learners. Seeing immediate results from applying these solutions is what matters to our learners today.

Our stakeholders are willing to sacrifice lengthy design documents in favor of early prototypes and delivering the right learning experience, at the right time, in the midst of changing business needs. Agile software development is now part of IBM’s standard engineering practices and is shared across the enterprise. Those of us on the learning design and development teams were gratified to see our learning solutions effect real and immediate change.