Wholemeal Ltd a consultancy run by Malcolm Locke, based in Christchurch, New Zealand, specialising in internet applications using FOSS.

Malcolm Locke

Malcolm has approximately 15 years of development and systems administration experience, cutting his teeth developing high availability Linux clusters in the UK for the 365 Corporation, serving some of the busiest sports websites in the world.

Malcolm moved to Christchurch, New Zealand in 2007, and has helped a number of local companies improve their infrastructure and development processes.

Whilst most of our work is confidential, we pride ourselves in the quality of work we provide and will be more than happy to provide a list of recent referees, contact us.

Agile development

One of the key differences between software engineering and other engineering disciplines is the capacity for software to be changed. Once the foundations of a house have been laid, the footprint cannot be easily changed. However, software is not such a concrete medium.

Agile development practises embrace this capacity for change, accommodating changes to specifications and requirement priorities throughout the life cycle of a project. By taking this approach, we are able to deliver maximum value in the shortest possible time, getting your product to market as soon as possible and adapting to changing market conditions and user requirements.

User Stories

The first task taken during project planning is to collect ‘user stories’. These are brief descriptions of tasks that users need to be able to perform using the software. Some example user stories may be a user should be able to request a new password or an administrator should be able to de-activate another users account.

We will gather as many of these stories as possible in an initial meeting between the customer and the development team. At this stage we will not go into great detail about the function of each user story. Estimation and prioritisation

Once the list of possible user stories has been gathered, the development team will estimate the relative difficulty of each story. This is usually done using a simple points system, with 1 being the simplest and 5 being the most complex. We call these ‘story points’.

Given this complexity knowledge, the customer will then prioritise the stories, the most important first and the least important last. This prioritised list of work is called the ‘backlog’.

The development team will then start working on these tasks in the order they are defined in the backlog. Iterations and velocity

Each project is split into ‘iterations’, usually 1 week long but sometimes 2. At the beginning of each iteration we will meet with the customer and discuss in detail the stories that will be worked on during the upcoming iteration.

Once two or three iterations have been completed, we average out the number of story points completed in the previous iterations. This figure is known as ‘velocity’ and allows us to estimate how long the remaining work in the backlog will take to complete. It also allows the customer to get a reasonable estimate of when any one story in the backlog will be complete.

The customer’s role

The customer plays a key role in the process. If you think of new features, you can add new stories to the backlog and prioritise them accordingly. If your business priorities change, or you need a feature sooner than previously thought, you can simply re-order the priorities.

Only the customer is able to set priorities. This ensures the development team is focussed on your requirements. We make the backlog available via a web based tool, so you can check on progress at any time.

Once a feature is complete, the development team will release it to a demo copy of your software where it is available for you to test. If you think the feature is complete, you can accept it. If it needs changing, you can reject it. A feature is only considered complete when you have seen it working and accept it.

Our tool set allows us to deploy features to live at any time in the project life cycle. We can deploy new features as soon as they are excepted, or bundle features into releases. Because we employ test driven development (TDD) practises, every piece of code is covered by automated tests and the possibility of introducing bugs into existing code is greatly reduced.

This means we can take your product to market early and continually improve on it’s functionality, and you start gaining revenue and user feedback as soon as possible.