Answer: One bite at a time.
An agile approach to doing your work is all about taking a big project and breaking it down into lots of small, bite-sized projects and doing them in order of priority.
In their popular book Getting Real, 37 Signals say it this way: "Instead of a 12-week project, think of it as 12 weeklong projects."
Built into this process is the option to change priorities or add and remove features along the way. If you've worked on any kind of project, you'll know that these kinds of changes are going to happen whether you like it or not. So my thinking is, you might as well plan for them. Make changes your friend instead of an uninvited guest :) Let's look at a concrete example.
Sushi Snack Shack training course (made up name, hopefully not trade marked)
I work in the learning and development field managing projects and doing some instructional design (designing training courses, workshops, e-learning etc). I also love eating sushi. Here's how you might build a training course on making sushi the agile way.
(Disclaimer: I only know sushi from standing in line and ordering it. Some sushi-specific facts my be inaccurate. It's only an example so feel free to post a comment to correct any of these.)
Ask the client, "What are all the things we want someone to be able to do at the end of this course?"
It's a beginners course so we'll say something like (in no particular order):
- Cook rice
- Serve sushi in a takeaway container (with extras like ginger and wasabi and sauce)
- Prepare ingredients
- Roll it up
- Assemble sushi roll
- Cut sushi into pieces
Ask the development team, "How long will it take to build a course that will achieve each of these learning objectives?"
When answering this question you are trying to think about building some training for each learning objective separately. Of course they will all come together in the finished product, you will just think about working on them individually. This might look like:
- Cook rice (1 day)
- Serve sushi in a takeaway container (with extras like ginger and wasabi and sauce) (1 day)
- Prepare ingredients (2 days)
- Roll it up (1 day)
- Assemble sushi roll (2 days)
- Cut sushi into pieces (1 day)
Ask the client, "What are the highest priority things for people to learn?"
So we'll put the learning objectives into order:
- Cook rice (1 day)
- Prepare ingredients (2 days)
- Assemble sushi roll (2 days)
- Roll it up (1 day)
- Cut sushi into pieces (1 day)
- Serve sushi in a takeaway container (with extras like ginger and wasabi and sauce (1 day)
Ask the development team, "What can you build in week 1?"
- Cook rice (1 day)
- Prepare ingredients (2 days)
- Assemble sushi roll (2 days)
The other items go into list of other stuff to work on but that we haven't planned yet. We'll call this list the backlog.
- Roll it up (1 day)
- Cut sushi into pieces (1 day)
- Serve sushi in a takeaway container (with extras like ginger and wasabi and sauce) (1 day)
The development team then build a training course that achieves the learning objectives planned for week 1. This week long chunk of time is called a sprint in agile terms (actually using scrum, which is one of several agile methodologies.)
They get some people to test that the course works (could be learners, other people on the dev. team or whoever can givereal feedback.)
Then the development team shows the client what they have built.
Ask the client, "Is that what you wanted?"
Because we are all looking at something that is real then it's a lot easier to come to an agreement on it. Writing specifications are no good because they are not real and changing them is too easy.
Then we revisit this list of other learning objectives (backlog) when planning what work we'll do during week 2. The beauty of this approach is the client can say either, "just do the next five days worth of effort in the backlog" or "we'll actually it's important for them to learn food hygiene, can we add that to the course next?"
Because we are continuously planning all we do is add food hygiene to our backlog and then
Ask the development team, "How long will it take to build a course that will achieve this learning objective?"
The backlog then looks something like this:
- Food hygiene (3 days)
- Roll it up (1 day)
- Cut sushi into pieces (1 day)
- Serve sushi in a takeaway container (with extras like ginger and wasabi and sauce) (1 day)
Ask the development team, "What can you build in week 2?"
- Food hygiene (3 days)
- Roll it up (1 day)
- Cut sushi into pieces (1 day)
And round and round we go.
The client will no doubt think of other stuff to add to the backlog over time. This is okay. When the training course is at the point where it can be used by the client it is released or published or goes live. It may not be the ultimate training course, but it meets the clients minimum needs for now.
Development of version 2 of the course can continue in the same manner:
- Add learning objectives to the backlog
- Estimate the effort required to build them
- Prioritising the backlog
- Planning the work for the next week (or sprint)
How would you bill a project like this?
When it comes to billing time, this agile approach works great for both the client and the development team. Because the dev. team is showing a working, usable product to the client at the end of each sprint, the client knows what they are getting and can pay for work that has been done.
If we used a waterfall approach of prototypes and drafts then after 2 weeks we would probably just have a draft of a course that achieves 20 learning objectives, but nothing final that the client can actually use. The client has to try to imagine what the finished product will look like. They also pay for incomplete work. While the sushi course isn't completed after week 1, the work done during that week is complete. What would you rather pay for :)?
Conclusion
Applying an agile approach to instructional design is not a new idea. However, it isn't widely accepted (ADDIE is still the methodology of choice) and probably needs more fleshing out. Definitely an open-ended conversation at this point. In the mean time, I've appointed myself one of the many agile evangelists. I'll keep working on examples and a model that you can use as an alternative to the traditional waterfall approach to instructional design. I think this is a good start. What do you think?