agile development
We develop our software using an
agile methodology. This approach enables us to be very flexible in
our development and very fast.
Before we start developing a new
version we create issues. These are functional descriptions of
all the new and changed functionality we want to make. All issues
together form the backlog. Development is done in two week
sprints. At the end of every sprint we have a new working version
of the software. This makes it possible to be very flexible in our
development and to be very effective. We deliver every new version
on time, with the desired functionality.
In order to do that, we work with several
windows, the future (one year and more), the next versions ( 4 - 12
months), the next milestone (2 months), and 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 any plan that lies 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 issues that give directions to our over-12 months
plans.
The next versions (4 - 12
months)
We already know which versions we want to develop for
the next 12 months and what they will be about. We privately 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 Subject Matter Experts
more into the authoring process. And we proudly 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
guiding lines for our product development and we 'collect' wishes,
ideas and new functionality in a backlog; an overview of all kinds
of development issues with a short functional description. We
assign each of these these issues to one of the future
versions.
Before we start working on a new version we go
through all assigned issues, we then either describe
them in more detail or we decide to move them to a later version.
Based on the descriptions our developers make a global design and
give us a an estimation of the work it will take to build the new
functionality. On basis of this information we establish priority
for each issue. We then divide all the work for the next
version into two milestones. We will assign the issues with the
highest priority and the ones that are very complex to the first
milestone.
The next milestone (2 months) and the next
sprint
Working with an agile software development method
means that our developers work on new functionality for two weeks
(a sprint) and deliver working software after each sprint. This
means that we (if we want) can still add, change and alter issues
and priorities before the next milestone. The only fixed thing is
the sprint planning, once we set that we will not change it,
otherwise we would disturb the development process. At the
beginning of each sprint our developers pick issues they will work
on from the backlog, 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 our
road map makes sure that we will not lose sight of our own goals
and development lines.