You can read the whole article or you can directy jump to one of the following sections:

• Our software and product development approach
• How does it work?
• Step 1: The Product backlog
• Step 2: The Sprint backlog
• Step 3: The Sprints
• Step 4: Code release

senseIT uses an interactive incremental development method called Agile Scrum that promotes the use of short iterations, teamwork, collaboration and process adaptability throughout the life-cycle of the project.

For research projects, after each iteration the customer can decide whether to continue or stop the complete project.

Agile Scrum has the following features:

• Customer satisfaction by rapid, continuous delivery of useful software
• Stakeholders are part of the (development) team
• Only fully functional and tested software will be released
• Short communication lines between sales, developers and stakeholders by using video conferencing
• Regular adaptation to changing circumstances by using iterations or timeboxes
• Stakeholders can monitor the progress via our webportal http://projects.senseit.nl

We use Agile Scrum in combination with test driven development which will be explained in the next section.

A scrum team does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint.
In the team you can find two special members:

The product owner is the project’s key stakeholder and represents users, customers and others in the process.
The ScrumMaster is responsible for making sure the team is as productive as possible. The ScrumMaster does this by helping the team use the Scrum process, by removing impediments to progress and so on.

In the illustration below you can see the essentials in Scrum Agile software development.

This graphic is an introduction to everything essential in Scrum agile software development. On the left, we see the product backlog, which has been prioritized by the product owner and contains everything wanted in the product that’s known at the time. The 1-2 week sprints are shown by the larger green circle.

Process flow of agile scrum development.

Each step of the agile scrum process will be explained now.

The Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable features or requirements. Typically, a project writes down everything obvious, which is almost always more than enough for a first sprint. Product backlog items can be technical tasks ("Refactor the Login class to throw an exception") or more user-centric ("Allow undo on the setup screen"). A very interesting prospect is expressing Scrum backlog items in the form of Extreme Programming's User Stories.
The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.

Together with the stakeholders the list of tasks is sorted from important to less important.

The product owner shows up at the sprint planning meeting with the prioritized product backlog and describes the top items to the team. The features from the product backlog are broken down in small tasks, also known as stories and a relative time duration is assigned to each story. The easiest story to implement has the value "1" and all other stories are compared with it (with a value from 1 to 10). Each team member has to assign a value and any differences for a particular story will be discussed.

The sprint backlog is property of the Team. Estimations are set by the Team.
With a scrumboard the process is visualized (Planned/In progress/Done) and the progress is show in a burndown chart.

This is our scrumboard used in an actual research project

Each sprint consists of a number of work that need to be completed in a certain amount of time, usually one or two weeks. At the end of each sprint, the team produces a shippable product increment - i.e. working, high quality software. This is ensured by using test driven software development.
Test driven software development has the following cycle:

1. Add a test

In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented.
To write a test, the developer must clearly understand the feature's specification and requirements.

2. Run all tests and see if the new one fails

This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test will always pass, and therefore be worthless.

3. Write code

Implement the test and make sure the test does not fail anymore.

4. Run the automated tests and see them succeed

If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.

5. Refactor code

Now the code can be cleaned up as necessary. By re-running the test cases, the developer can be confident that refactoring is not damaging any existing functionality. Remove all duplication and non relevant code.

After the code is refactored, the code will be validated by another developer. When both developers agree the code is clean and functional then, and only then the code can be commited in subversion.

senseIT uses advanced tools and statistics software to ensure that only high quality code is checked in subversion.
Development in c#: fxcop, Coverity, Test driven.Net etc.
Development in c/c++: Boost libraries

A build machine runs all tests at night and compiles all code in to release versions. Warnings and errors will be reported to the scrum master.

6. Repeat the whole process with a new test

Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small - as few as 1 to 10 edits between each test run.

The functional execuble will be released via the webportal and can be reviewed/tested by the customer.
The feedback of the customer will be used as stories in the next sprint (see illustration below).

Sprint iteration process

During a sprint the following meetings are held:

• Sprint Planning Meeting

In the sprint planning meeting there will be selected what work is to be done and by whom. Identify and communicate how much workis likely to be done during the current sprint.

• Daily meeting

Every day in the morning each member will explain what is implemented the previous day and what will be done the current day. Also possible impediments will be discussed.

• Sprint Review Meeting

A presentation will be given to the stakeholders. Also the completed work will be demonstrated (a.k.a. the demo).

• Sprint Retrospective

All team member reflect on the past sprint.

The code will be compiled into an executable. The executable, along with all its dependencies (drivers, external libraries etc) will be embedded into a setup.
The setup will be tested on different platforms via virtual machines and is then accessable for customers as beta version in our webportal.