Developing courses is hard. It takes a lot of work and is time consuming. According to the Association for Talent Development, it takes anywhere from 40 to 200 hours of work to produce one hour of course content, depending on the type of course you build. By these standards, it takes weeks to create a single half day course, and months to build a multi-day course.
You don't have that kind of time. By the time a course is delivered to a customer, key features in your product have most likely changed. Traditional instructional design processes are not keeping up with the increasing pace of software development. This is a common problem that needs to be solved.
As software course creators, we need to ask ourselves, “What can we learn from software teams and how they build products, to build courses faster, and with higher quality?”
Is Agile the Answer?
There's a lot of talk about agile and "being agile" as a means of solving all our problems. Agile is a buzzword. You might equate it with vague references to being nimble, moving fast, and readiness to change course at a moment's notice. But just working faster offers us nothing more than a frazzled life of uncertainty, doubt, and stress. That is no way to live.
This is the first in a series of blogs related to our eBook: The ServiceRocket Guide to Better Agile Course Development. We provide a predictable process for developing high-quality software courses. We demystify agile, as it specifically relates to course development.
Instead of telling you to be nimble, we offer a specific process for you to follow. We define each step in the process and show you how to apply the framework to the real world of developing software training courses. This agile process is called Scrum. If you follow it, you create a clear path for developing courses that are well developed, customer-focused and more quickly available to your customers.
Image Credit: https://commons.wikimedia.org/wiki/File:Scrum_Principles.png
What is Agile?
Agile was developed by a group of 17 software developers frustrated with their existing ways of creating software products. They wanted to define a set of principles to guide processes for building better software, faster, and focused on customer needs. This is what they wrote in 2001:
Manifesto for Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That's it. Simple. Agile is a set of principles. Not a methodology. In fact, there are several methodologies that are based on agile principles; these include:
rapid application development
unified process
dynamic systems development method
scrum
crystal clear
extreme programming
feature driven development
Although the above were developed for software development work, there's no reason why agile principles cannot be applied to any other function in a business, including designing training courses. It is already happening.
Instructional designers have created agile methodologies of their own. Two such examples are the Successive Approximation Model (SAM), developed by Allen Interactions, and Llama (Lot Like Agile Methods Approach) by Megan Torrance. We recommend you read up on these processes to find out if they are a good choice for you in your organization. Scrum provides a well-defined process to deliver a product (in our case training), and empowers the team to run it.
What is Scrum?
Scrum, developed in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka, is an agile framework for completing complex projects "continuously, incrementally, and spirally." The Scrum Alliance defines scrum as:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Clear as mud. And while this is the technical definition of scrum, we know you're thinking, "That's great, but how does that help me develop my next course?" We clarify what scrum actually means for you, to develop and deliver better, customer-focused courses, faster.
Why Scrum?
There are five reasons to use the scrum methodology for building software courses.
Focus on delivery. One of the most important outcomes of scrum is that something of value (a product) is delivered to your customer very early in the process, and then repeatedly at regular intervals throughout the course of a project. Your customer sees the product early, provides input into its development along the way, and sees visible improvements over time. Your progress is visible, because you deliver working versions of your product, in our case a course, throughout the project.
Urgency of time-bound constraints. As you know, creating a course can take weeks or months. It can be an overwhelming experience. Scrum provides time-bound, clearly defined project sprints. Each sprint requires that something be finished and delivered. Sprints breaks down projects into short bursts of work, which are clearly defined, and easily manageable.
Team members own their work. The beauty of scrum is that team members (which includes course developers) own and completely decide what tasks go into a sprint. The result is that team members reach their deliverables more consistently than with traditional approaches.
Continuous learning. At the end of each sprint, team members take time to review the successes and failures of that sprint with the goal of improving the next sprint. The team gets better throughout the life of the project. Work estimates, meeting deadlines, and incorporating feedback into the course all improve, resulting in a more successful project.
Clear roadmap to success. As you learn in this book, scrum provides a clear roadmap to success. It's a way to easily show management what will be delivered and when. Each sprint provides a short-term milestone with a defined output the team can point to. When requirements and timelines change, and they will, you still use the framework of future sprints to estimate the project and deliverables, bringing visibility and predictability to the project.
In our next blog, we cover the scrum process.
This article originally appeared on the Learndot blog on June 27, 2017, and is co-written with Bill Cushard.
Comments