- 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-awayThe 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!