Agile eLearning development: business goals and road map


This is a first post in a series of post on Agile eLearning development. This series is sparked by the book ‘Leaving ADDIE for SAM’ by Michael Allen and Richard Sites. I wrote a book review on it (and it love it). I do believe that agile software development can offer us even more very practical ‘best practices’ that we can apply to eLearning. Michael told me that he is working on a new book on agile project management, that will also address this. In the meanwhile I would like to share with you our best practices. The idea is to go over the process of agile software development at easygenerator and translate that into eLearning development. I will start with the ‘long term planning’: The road map and how to connect learning to your business goals.

Before I can do that I have to introduce the roles in this process and map them to ‘e-Learning development roles’.

Software role eLearning role
The Product Owner (PO), he is the most important person in this process. He is responsible for the ‘What’. What will we develop in the next 12 months. He translate the demands from the market into product demands. In corporate eLearning terms this will be the manager of the Learning department. He will translate the training demands of the company into goals for the learning department. When we are talking eLearning projects this will be the Project manager
Market. Partners, customers, end users, competitors all have developments and demands. This is important input for the road map. Your market are the users of the learning objects (both managers and end users), but also by general developments in the eLearning market with vendors and other companies and theoretical and technical developments.
Innovation. I have put this down as a separate element. Innovation comes from the development team, the organization, users, customers, the market.  If you don’t pay separate attention to it, it will be something that you strive for, but never achieve. Exactly the same here
System architect. A ‘double role’. The system architect checks planned development for technical challenges, but at the same time he will have independent input for the road map. In our case things that have to do with our technical backbone, security, performance. I don’t think that there is a eLearning equivalent for this role. But there should be. Just think of all the technical developments around mobile, standards (like Tincan) and other technical stuff. You need more than a technician to manage this.
Road map. The document that contains the global goals and plans for the next 12 months. This would typically be a year plan for a learning (or HR) department or a ‘customer plan’ for a client.
Development team. The team that builds the software. The team that builds the learning components.

Agile software and elearning development

The road map

We like to look ahead, but no more than 12 months. Therefore the road map documents looks 12 months ahead. We release a new version of easygenerator every 2 or 3 months (we are working on a release every month). This means that it is not a plan for 2013, but it is a plan that always looks 12 months ahead. Before we finish a release we need to renew the road map so it will still look 12 months ahead. The road map is driven by our business goals and will set the development goals on a high level.

Business goals and road map
This means that the first step is to get clarity on the business goals and how they will influence the product development. We use a method called impact mapping. There is a free tool called effectcup that supports this whole process. The Product owner takes the business goals (input CEO) and figures out what this goal means for key persona’s. What activities do they need to be able to do. And which user stories describe these activities. Our business goals are things like:

  • Sell more licenses
  • Sell easygenerator as internal authoring tool to LMS vendors
  • Keep existing partners and customers happy

The road map document is in fact a short document with a bit more explanation about the why of the business goals that you can present to other stakeholders.

eLearning
The trick is to figure out what people need to be able to do in order to achieve these goals. The translation to eLearning is very simple. I love the action mapping approach of Cathy Moore (see a post I wrote about this earlier). It is a one on one translation of impact mapping to eLearning. She also stresses that learning is not what people need to know, but what they need to do. That is the reason she calls it action mapping. You could use a tool like effectcup to assist you in this.

It works for a learning department or a eLearning project. For an eLearning department it is the first step in connecting learning to the business, and it is the foundation of a possible ROI calculation. When you do eLearning projects it is also very helpful. Instead of executing a project this will give you the chance to sit down with your client and talk on a much more strategic level to them.

Another important thing is that you don’t get into solutions at this point. You describe what the learner (worker) needs to be able to do. Not what kind of learning experience you are going to offer. Measuring their (hopefully improved) performance will tell you your ROI.

This post is part of a series on agile eLearning development:

More post will follow over the next few weeks.

Valve handbook: an unique way to organize talent and business


This week I was having dinner with Hans the Zwart who is a former colleague of mine. He is one of the most well-read people I know and when he gives me a reading tip, I will read it. This time he mentioned the Valve ‘Handbook for new employees‘. Valve is a game company (known for Half-Life, Team Fortress 2, and Portal and the digital delivery platform Steam) which is organized in a unique way. The handbook is an internal guide for new employees in order to ‘not freak out’ when starting to work in an organization without any formal structures.

It really is a very interesting read. At Valve there is no hierarchy, no formal job description, no bosses, nothing of the structures you would expect in a company that has some 300 employees.

People decide themselves what project or product they will work on and what kind of contribution they will make. The idea is that they are best capable to decide where they are of the biggest value for the company (and for the customers). Roles are fluid and can change when the requirements of the work change. Projects are voted on by feet (or better wheels). If you find a project interesting you can just roll your desk over (they have wheels) and start participating. Everybody can start up new projects or products, all you need to do is convince other people to join you.

When evaluating people they will use a peer evaluation along four dimensions:

  1. Skill Level/Technical ability
  2. Productivity output
  3. Group contribution
  4. Product contribution

Based on this peer evaluation they will ‘stack rank’ employees and based on that they will decide on their compensation. Not surprisingly ‘Hiring’ is the most important process in this company. Getting the right people in is crucial for such kind of organization. They use the same four dimensions when hiring and they are looking for what they call T-shaped employees.

This means people who are generalist, but they also are an expert in one field. This is the best guarantee that people can collaborate in a team and will have added value to that team.

There is a lot more to read in the 55 pages, so please do. For me books like this are interesting because the ideas are so far out of the box that it stretches your own boundaries. In this case it will even remove boundaries. It will change the way you look at your own organization and that is always a good thing.

By the way. Another tip from Hans, his favorite movie ‘The big Lebowski‘. And if he says you should watch it, you should.

Business lessons from long distance running


I like to run ‘long’ distances. I did put quotes around long because I’m a middle-aged guy who is somewhat overweight (since my last attempt to quit smoking). For me long is a run between 8 and 15 kilometers. So I’m still a long way from a real marathon.  But my runs are long enough to let my thoughts run free and sometimes they even run pretty deep.  Today I was thinking about the similarities between a 10k run and running a company, I decided to share them with you.

Running business
My best runs are the ones when I don’t even know that I’m running. Sometimes my thoughts just wander off and I cover kilometers without even noticing it. The running goes automatically.

When I run I always have music on. I have a special playlist on my iPod, with songs that have the right pace for me to run on. They vary from Eminem via the Red Hot Chili Peppers to David Bowie. The music helps me not to focus on the running.

It occurred to me that running a business is a lot alike. You have a long distance goal (for easygenerator becoming to number one learning authoring environment in the world) and you have to make sure that every step you take will bring you closer to your goal. On the other hand this goal is far away so you don’t get real energy from it. If you only focus on achieving your long-term goal it will cost you a lot of energy to keep moving in that direction. You have to enjoy every step of the way. Music does that for me while I’m running, I’m enjoying it intensely. Projects, customers, partners and colleagues are my ‘working music’. They fill your working live every day. And enjoying what you do with them and achieving short-term goals and celebrating your successes give you energy.

With running selecting my music is important, if it doesn’t have the right rhythm it will upset my pace, I don’t have any slow songs in my playlist. The same goes for projects, customers, partners and colleagues. Before you start with them you need to asses if they will bring you closer to your goal. If not don’t bother, If they do go for it and enjoy it, get energy from them.

Looking back is better than then looking ahead.
A presenter in a workshop was telling a story about her running experiences, and she told me she got a golden tip from a friend: “Never think how far you still have to run, but remember the distance you have already covered”.

Sometimes when you are running it is difficult to keep the pace. When you are experiencing head wind, or have to climb a dike or hill it will disturb your rhythm and you become very aware of the fact that you are running.  These are the moments you notice that you are getting tired and that your legs are sore. Looking back on the distance you have already covered and how well that went helps a lot, it’s like your achievements are pushing you forward again. Way better than thinking of the miles ahead with a strong head wind. The same goes for running your business.

 

Follow

Get every new post delivered to your Inbox.

Join 1,088 other followers