Someone recently asked me whether we used an ‘agile’ approach to developing software. So I thought I would post a few words about our experience of Agile:
What is Agile?
The conventional approach to producing software is that you decide what need to be produced, write a specification, develop the software, test it, and have a finished product.
With an ‘agile’ approach, you have a number of ‘sprints’, or ‘increments’ lasting 1-4 weeks, where, in each of these sprints, the team adds a part of the functionality of the final product, tests it, and releases a version ready for use, with the final ‘sprint’ resulting in the finished program.
Agile also has a couple of interesting terms, which come from rugby: the team is supposed to have a ‘scrum’ or get together every day to discuss progress, and the person in charge is called the ‘scrum master’. The word ‘sprint’ comes about as the team sprints for the line (to get the software completed).
The short answer is that we don’t use an agile approach to develop our educational software. One of the reasons is that we can’t release a program that is anything but finished, and there usually isn’t a half way stage we can get to.
We also know that writing the software (and getting in audio and graphics), whilst not quick, is the “simplest” part of creating a new title. We know how to write software, it is time consuming, but straight forward.
The hard part is knowing what needs to be produced, and as such, we do need to spend quite a lot of time creating a new title: this means thinking of the idea for a program; working out how to make that into a good interactive activity; and then adding the details for the program (what the screens will look like, what happens when buttons are pressed); and what graphics, animation and audio will be needed.
We also realise that we are creating something, and that does not always lend itself to the idea of sprints (and the implied sprint deadlines). Yes, we can knuckle down and get things done for a sprint deadline, but having done that and realised that with an emphasis on speed, we haven’t noticed that what had been created wasn’t quite right!
Work in industry
I have also worked in industry where the ‘agile approach’ is often spoken about. The overall development is broken up into ‘sprints’, with milestones for each sprint. For example with a system that is being used, but needs changes, it’s a matter of implementing some of the changes, creating a version of the software that can be used (in a sprint), before going on with the next set of changes in the next sprint.
An all new system, is a bit like our educational software, where time needs to be spent working out what needs to be done at the start. After that the software development can be broken down into sprints. In this case, what needs to be done will have been agreed with clients etc., so there is more certainty, and sprint deadlines need to be followed.