Sunday, June 14, 2009

The Agile Elearning Design Manual - Agile Re-explained

In my last post we looked at the problems with our existing approach to building elearning. In summary, the problems we noticed were:
  • A lack of shared understanding within the team, about the the customer's learning problem.
  • The high risk associated with not having generalists in the team.
  • The delay in seeing working pieces of elearning.
  • The time spent in creating documentation and in analysis.
  • The risk of endless reviews and amendments.

In today's post I'd like to introduce Agile thinking. Now this post may seem very philosophical, but it serves as the context that we keep referring back to each time we start developing elearning. In fact for those who haven't ever heard of this approach before, Agile is an extremely mature software development methodology, and surprise, surprise its the approach we follow at ThoughtWorks! A couple of questions to answer first up:

Why are we using a Software Development Methodology for creating Elearning?

Elearning development isn't very different from Software Development. In fact, if you look at it, any piece of Elearning is really a software program often written in Flash. Now the tools that you use, may have varying levels of sophistication and that's true on software projects as well. The final output requires as much of the scientific mindset of a programmer as it does the creativity of a User Interface designer.

I am a one-woman-team. How does this methodology apply to me?

A lot of the team related practices may not apply to your current situation. Who knows what may happen tomorrow? There are however a lot of practices that you will find relevant whether you're part of a team or not. Stay tuned each week and you'll see what I mean.

Is this your invention?

"One good thief is worth ten scholars." - Randy Pausch.
No, not at all. I'm not wise enough to invent anything -- I am trying to distill the wisdom from various approaches that I've seen and been amazed by in my career as a learning professional and most recently as an elearning designer. So you will find thoughts from Jane Hart, Cathy Moore, Tom Kulhmann, a thousand ThoughtWorkers and many others that I'm "stealing" to piece together what I call the Agile Approach to Elearning. Hopefully, you'll see the nuggets I'm trying to place in front of you and go back to the original source to learn more.

Can I apply these principles to Instructional Design for Classroom Training?

Yes you can! That said, some principles may not apply to your current situation or work. You may have to go on the same journey as mine to determine what works best for you and what doesnt.

If you have more questions, please do comment on these posts or email me and I'll be happy to answer them for you. So, without further ado -- lets set some context!

The Agile Manifesto


If you look at the Agile Manifesto, you'll see that none of the trade offs seem revolutionary. They're exactly what you'll call common sense. If you look at my modified manifesto above, you'll perhaps notice the same common sense.

If a customer had to trade off between Engaging Elearning and Comprehensive Documentation he would certainly choose the former. We know that when we provide a service, its the people that provide the service that matter the most. We also understand the importance of communication and more importantly conversations. So we choose Individuals and Interactions over Processes and Tools. Negotiating scope doesn't solve the customer's problem - Customer Collaboration does! And yes plans are important, but Responding to Change becomes more important, because a customer doesn't change their mind just because they want to! They change their mind or ask for a change in the elearning because it serves their business goal much better!

The key thing to remember is that there's definitely value in the items on the right. In the case of a trade-off, we value the items on the left a lot more.

While I run the risk of metamorphosing this post into a Wikipedia article, there are a few principles that I feel are key to understanding Agile Thinking:
  • Customers really appreciate progress when they see working elearning. Getting this out quickly is our primary focus.
  • Face to Face conversations are the best way of understanding the customer's problem and designing a viable solution.
  • Change is the only thing that's constant - the longer we take to show the customer working elearning, the more likely his needs are to have changed. Shorter releases ensure quicker feedback thereby helping us stay abreast with the customer's requirements.
  • A group of motivated and skilled individuals in the right environment will get the job done.
  • The best designs will emerge from self-organizing teams rather than those that are heirarchical in their organization and their workflow.

Key Take-away

The manifesto is our guide to making decisions throughout the length of the project (big or small). At each point we should question ourselves against the manifesto. Are we collaborating with the customer? Are we creating documentation as against creating elearning? Are we focussing on conversations or are we following process? Are delivering to plan or delivering to the customer's needs?

I know that elearning project managers who've run fixed price projects will scoff at this approach, but really the contract shouldn't dictate the development process. It should dictate how we engage the customer and it just means that we keep an eye on risks a lot more, talk to the customer early and often! More about this in a later post perhaps!

The Guiding Values

Yet again, the Guiding Values are our benchmarks to ensure that we're on the right track with our approach and our selection of practices. I'll try to be brief in my descriptions:

Communication

The builders deliver business value to the customer. Its important that they have shared understanding about the goal and the task on hand. To this end, we favor simple designs, common metaphors, collaboration of users and builders, frequent verbal communication, and feedback.

Simplicity

We start with the simplest solution that satisfies the customer's need. Bells and whistles can then be added later. We keep our course modular, so that different parts adress how to do different things. We try to keep knowledge acquisition separate from teaching skills. We try to avoid complicated functions that can otherwise be delegated to a Learning Management system. Looks are important -- but we avoid 'complicated' graphics as far as possible. Our design meets today's requirements - not those of a year later! Simplicity in design and building should improve the quality of communication - everyone should be able to understand what different parts of the elearning module do and how they work together.

Feedback

You don't know how well you're doing until you have feedback. We need to show the customer working elearning ASAP, so that we know what we're doing right. The team needs to be able to critique the design and evolve it over time. The design should accomodate this critique. The team needs to be able to give itself feedback about its approach and tweak it from one run to another.

Courage

Courage can be displayed in many ways. Builders can point out issues in the design to the rest of the team. The team should feel comfortable to throw away a piece of work since it didn't serve a purpose. Courage means persistence - we stick at it to solve the customer's business problem. Courage is also a project management thing - we ensure that the team has a sustainable pace and no one's on a deathmarch!

Respect

Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through continuous improvement.

Next up -- the Practices!

Here's the point at which we'll start to talk about the practices. While the values and the manifesto happen to be our guiding light, we need real. solid practices to take to the ground. In the next post, I will get to the stuff beyond the fluff! The contents of my next post will address the life-cycle of an Agile elearning project and how you can conduct an Inception for such a project. Stay tuned, I've got loads to share with you!

4 comments:

Cathy Moore said...

I'm looking forward to seeing more in this series. If you aren't already familiar with it, you might be interested in the "SAVVY" process used at Allen Interactions:

http://www.alleninteractions.com/savvy-process

globetrottingkerry said...

I'm just catching up on this series today. I find it really quite relevant given that i've just finished working on an eLearning project for an agile software implementation. This is a great resource!

wynwar said...

Hey Sumit,

Great Series!!

The pictures in this one are not working though. Please have a look into this when you have time.

Thanks

Vinay

Web Designer said...

That is very interesting Smile I love reading and I am always searching for informative information like this. This is exactly what I was looking for. Thanks for sharing this great article

Related Posts with Thumbnails