In the previous post on agile eLearning development I wrote about culture. I have done some change management in the past, so I know a change in culture is one of the most difficult changes. But there is hope. Agile development offers a range of best practices that are relatively easy to implement. In the next posts I will describe a few.
Demo
Agile development works in short sprints (one or 2 weeks). After every sprint there is a demo where the development team shows the result of the work of the past sprint. At easygenerator we now work in one week sprints. Every Tuesday at 10 the team will show their results. The product owner will check during the demo if the solutions build match the requirements from the user stories and will accept them (or not). I am present (as CEO) and some more colleagues. But we also do invite partners and customers to join us in the demo, this way giving them the ability to get connected to our development and offering them the opportunity to give their input during development. A demo takes 1 hour.
This is an easy first step to implement and if you do it will change your professional life. You don’t have to implement an agile process to do this. When using Addie you can also do this. It is the ideal way of involving your client in the development process. Taking them along in the process, showing early results. But if you see something live you will experience it in a different way than when it is described on paper. How many times did you build an eLearning solution that met the requirements, but still the client wasn’t satisfied. This will solve that once and for all. The other thing is that you will sometimes find that good is good enough. This approach will give the client a chance to say “OK this will do, let’s put it live”; giving you a happy client and a project delivered early!
There are many ways to involve a client in the process but showing your intermediate results and make your whole process transparent to them is really great. If you are not ready to do so, at least consider showing your intermediate results to the client (by using for example the preview function that is available in tools like easygenerator). That would already make a big difference.
User stories
The heart of agile development is formed by the user stories. With an agile process you don’t create all kind of documents that describe the solution from several perspectives, you just create user stories. Of course they need to be connected to the goals (as I described in an earlier post). A user story describes a change or new functionality from the perspective of a user. It will describe what the user is able to do. A user story can be initiated by an idea or a problem (bug). User stories form the connection between clients and technicians. Both of them understand functionality described in terms of what the user can do. A user story must be small enough to be realized within one sprint. This means that larger stories need to be divided into several stories, with the advantage that they remain manageable.
In an eLearning project they will describe what the learner needs to be able to do (which gives a great connection to learning goals and the Action mapping approach. (by the way do you see the resemblance between a TinCan statement and a user story?).
The backlog
All the user stories are put in a so called back log, a big collection of user stories that need to be done. There are software programs that help you manage a backlog (we use a program called Gemini). This application plays a crucial role in the whole process.
After a user story is created we assign a priority to it. At easygenerator this is done by the product owner with input from me. In an eLearning project this would be the project manager and the client. Based on the business goals and business impact we will assign a first priority. Based on the priorities and we present a part of the list to the developers. They will make rough estimations for these stories (a special process with story-points, that I will cover in my next post). After this is done we (the Product owner and me) will determine the final priorities. Sometimes you want something badly, but if it takes a lot of time (and money) you will at least reconsider the priority. Based on the estimation we also will have a good idea what we can do for the next version and what not.
This results in a list of user stories assigned to the next version in the backlog. When starting a new sprint, the developers pick any of the user stories with the highest priority and start developing.
This post is part of a series on agile eLearning development:
- Post 1: Review on Michael Allen’s book ‘Leaving ADDIE for SAM
- Post 2: Agile eLearning development: business goals and road map
- Post 3: Agile eLearning development (2): Culture
- Post 4: Agile eLearning development (3): Best practices, Demo’s, user stories and backlog
More post will follow over the next few weeks.
The Learning 2019 conference
I have been to a ton of learning conferences but this will be my first time at #learning2019. I’m looking forward to it and I’m planning to report on all interesting sessions via this blog.
