What Learning Designers Can Learn from Agile Software Designers

I have always been fascinated with software design, even as a young kid learning BASIC on a Radio Shack TRS-80, I wanted to make that computer do stuff. The problem was that when the sun came up, I wanted to go fishing or skateboarding or play baseball with my friends. Although part of me always enjoyed it, I began to see software design like golf or windsurfing, which is to say, one has to spend a lot of time to get good enough for it to be enjoyable.

As I began my career in learning experience design, I found an interest in designing training classes and learning activities that help people learn something useful for their jobs. I have a few friends who are software developers, and I occasionally pick their brains about design processes to see what I could learn and perhaps apply in how learning experiences can be designed. Once I heard the phrase, agile scrum master, I knew I had to learn more.

When you begin to research Agile programming methods, you quickly come across a manifesto, written by agile software developers in 2001 to describe their beliefs about how software should be designed. I find the manifesto applicable to learning design, and thought I would share it.

So here is the Agile Software Development Manifesto:

What Agile Values:

• Individuals and interactions | over processes and tools
• Working software | over comprehensive documentation
• Customer collaboration | over contract negotiation
• Responding to change | over following a plan

While there is value in the items on the right, we value the items on the left more.

It seems like a reasonable set of values that could be applied to many disciplines, right? As I thought about each of the values more, it conjured up memories of many learning projects and how they could have been improved if we knew about the Agile Software Development Manifesto and could take a few lessons from it. So I looked at each value one at a time and came up with how it could apply to learning design.

Individuals and Interactions | over processes and tools: In my experience, learning professionals are people persons, yet in our insecurity, we focus hard on following processes and using the right tools. For example, many instructional designers are so obsessed with following the ADDIE process that they run their teams like a tyrant ruled by the five steps in ADDIE. Another example of this fixation with processes and tools that that we associate rapid instructional design with “rapid instructional design” software tools like Articulate, Captivate, Jing, etc. Don’t get me wrong, these are great tools. But you don’t need software to rapidly design learning experiences. Just ask Thiagi or read the Accelerated Learning Handbook. We could learn a thing or two from the agile manifesto and that our learning designs should be much more focused on individuals and interactions that with our processes and tools.

Working Software | over comprehensive documentation – “Why did you design that learning activity? What does the design document say?” I have worked on e-learning projects on which we had more time, effort, and pages on content wrapped up in standards documents, design documents and storyboards than in the actual delivered learning modules. I had always thought we had it backwards. Had we delivered the learning module sooner, in beta form to a pilot group, we could have collected feedback, iterated, and delivered a much better project, much faster.

Customer Collaboration | over contract negotiation – “I’m sorry, customer, we cannot make that change, it’s not in the statement of work. However, we can have a meeting next week to discuss changes to the scope of the project. But I must warn you, I sense this is a significant change that will likely change the contract. You understand.”

Responding to change | over following a plan – Yes, it is true that Winston Churchill said, “Failure to plan is planning to fail.” But Dwight Eisenhower said, “Plans are worthless, but planning is everything.” So which is it? Certainly one can plan so much that action is delayed or never taken. On the other hand, some measure of planning is important so that a designer knows what to expect and when to possibly expect the unexpected. A learning designer learns very quickly that well laid plans in organizations change quickly. However, many are far too rigid about following design documents and previously agreed to project scopes. Sales VPs change their minds. Customers cancel orders. Or better yet, the business lands a ton of new customers unexpectedly causing a hiring spree that forces all annual plans to be discarded by February. Responding to change and being OK with it, is a crucial skill of a learning designer.

I am not suggesting learning designers discard our very own tried and true instructional design model. At least not yet. However, I do think we can learn from other disciplines and perhaps improve how we design learning experiences. After all, our goal is to design learning experiences so that our constituents learn something valuable so they can performance their work, not follow a process or a design scope. Think like an agile software designer.

Bill Cushard, author and Director of Training and Development at Allonhill, is a learning leader with more than 12 years of experience in training and performance improvement at companies such as E*TRADE Financial, Accenture, and Time Warner Cable.

Share this on