CEO of Easygenerator

The Masie center brought out an eBook on Learning Strategies. This book was coined by an article by Gadi Amit in Fast Company. His point was that you can’t plan and create strategies beyond a 18 month window, there are just too many things you don’t know. In the Masie eBook 8 learning strategist talk about their strategy. The organizations these eight strategist work for is very different (from CIA, CNN, Waste management Inc, Shell, DIA, Eaton corporation, Farmers insurance and Lloyds banking), but the trend is that they support the view of Amit.

For easygenerator this is also true. Due to the shorter outlook of our customers we have to respond faster to new developments. But we still need time to design and develop great quality software and guard our own direction and development lines.

In order to do that, we work with have several windows, the future (one year and more), the next versions ( 4 – 12 months) the next milestone (2 months), the next sprint (2 weeks). For product development we don’t plan anything beyond a 12 month window.

The future (more than 12 months)
For us the future is anything that is further away then 12 months. We have our Vision and Mission in place that give us direction both in product development and in marketing and sales. Lines coming from this are our SaaS approach, the wish to work with local partners, our conviction that we need to facilitate both e-Learning experts and non e-learning experts, our goal to bring e-Learning to the workplace and markets we want to target. These are all things that give directions to our 12 months plans.

The next versions (4 – 12 months)
We do know for the next 12 months which versions we want to develop and what they will be about. We internally give names to our versions, these names show the main goal of a new version. We called the April version the ‘workflow’ version, because it focused on collaboration. The ‘SME’ was the July release because it was centered around involving the SME more into the authoring process. And we call our October version ‘Las Vegas’ because it targets for our US launch at the DevLearn conference in Las Vegas in November.

We have a road map document that outlines the red lines for our product development and we ‘collect’ wishes, ideas and new functionality in a back log; an overview of all possible development issues with a short functional description. We assign these issues to one of the future versions.

Before we start working on a version we go through all assigned issues, we describe them in more detail or we decide to move them to a later version. Based on the description our developers make a global design and give us a an estimation of the work it will take to build the functionality. Based on this information we give each issue a priority. Than we divide all the work for a version into two milestones. We will put the issues with the highest priority and issues that are very complex in the first milestone).

The next milestone (2 months) and the next sprint
We use an agile software development method (see older blog for more detail), this means that our developers work on new functionality for two weeks and deliver working software after each sprint. This means that we (if we want) can add, change and alter issues and priorities for the milestone. The only fixed thing is the sprint planning, once we set that we will not change it, other wise we would disturb the development process. At the beginning of each sprint the developers will pick issues they will work on from the back log, starting with the ones with the highest priority.

This process allows us to respond to new developments within weeks and that is something we really need in this ever faster changing environment, but at the same time it makes sure that we will not lose sight of our own goals and development lines.

· · · · ·