Web development: how we work

SWAP is a small team tackling a fair number of projects of various complexities. Therefore, we need to be both organised and reactive. This is the main reason why we have adopted an Agile-like development and management strategy, which benefits both the SWAP team and our clients.

What is Agile development?

In a nutshell:

Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change. It is a conceptual framework that focuses on frequently delivering small increments of working software.

Source: Wikipedia

Since its creation, SWAP has been busy developing its work methodologies and the tools required to make them work. They include a request process, a workflow, a web development framework and an easily configured templating system.

The request process

Clients (you!) are at the heart of the Agile methodology, where they are recognised as playing a key role. Typically, clients (or customers as they are often called) can be identified as both: (i) the person(s) or team(s) requesting the development of a web site or product and (ii) the end-users of said site or product. Both groups can determine (at different levels) the requirements of the application and, when delivered, its fitness for purpose.

The Client plays an important collaborative role during the lifecycle of a development project. This collaboration allows to properly estimate needs, to set up priorties, to deal with changes and to regularly evaluate progress.

This starts right from the early-envisioning phase, e.g. when submitting a research proposal for funding. At this stage, Client and SWAP meet, discuss potential requirements and a broad overview is made of what might be needed. From this, we estimate the time that should be budgeted in the proposal and keep trace of the discussion for later referral.

When an official request for a project or site is received, we kick off the development process by reviewing and updating the basic requirements.

The Client's collaborative roles

  • Establish requirements
  • Support in planning build iterations
  • Evaluate interim deliverables
  • Evaluate needs for changes during project lifecyle
  • Evaluate deliverables quality
  • Give feedback
Why is this important?

In a collaborative role, the Client has more input and control of the development process. This bolsters good relationships and leads to greater customer satisfaction.

Workflow: from concept to product

Our basic workflow is made out of four phases: Envisioning, Planning, Development Cycles and Deployment.

Agile new web site top level chart
New web site or application development top-level workflow.


In this phase, Client and SWAP sit down and discuss:

  • The purpose of the web site or application
  • Who the target users are
  • Must-have and nice-to-have features
  • Information architecture (IA),
  • User interface requirements (UI)
  • Basic technical requirements
  • What data (if any) it should use and how
  • Branding and visual identity
  • Cooperation with other teams

During the envisioning meeting, many different practical topics are covered that will allow us to get started on your site or applications. The choices made here determine the principal, early technical requirement — keeping in mind that some of these may change in the future.

Site request option example 1 Site request option example 2 Site request option example 3 Site request option example 4 Site request option example 5 Site request option example 6 Site request option example 7 Site request option example 8 Site request option example 9 Site request option example 10 Site request option example 11 Site request option example 12 Site request option example 13 Site request option example 14 Site request option example 15

Some topics discussed during the Envisioning phase

View part of our standard request sheet


The Planning phase is usually fairly short. During Planning, Client and SWAP typically settle on development milestones, priorities and time frames for deliverables. SWAP factors in the various requirements made during Envisioning and a vision of how development should proceed emerges.

Importantly though, we know that Planning is not set in stone and always keep Ziv's and Humphrey's Laws in mind.

Ziv's Law states that software development is unpredictable and that the documented artifacts such as specifications and requirements will never be fully understood. When you are creating something new, regardless of the amount of similarity to what has been created before, it is impossible to be certain of all the needs and constraints right from the start.

Humphrey's Law states that users do not know what they want until they see working software. Clients and users often translate this by saying: "I'll know it when I see it". Indeed, as they interact with the software, they gain insight on its potential and functionalities, often triggering ideas for additional features or revised interfaces.

Development cycles

Unsuprisingly, this is when the development of your web site or application starts. Development work is carried out in various phases, or cycles, all of which covering relatively small time frames. Remember: in Agile, we favour frequently delivering small increments of working software.

For each cycle, the tasks or "backlog" (e.g. planned software features, change requests, newly arisen issues, etc.) are chosen, prioritised and an estimation of the amount of time required for each is made, so as not to overflow the cycle. For each task, we make sure that a clear description is available — if not, Client collaboration will be required and the task is moved to a following cycle.

The tasks then get assigned between developers. Each developer signs in to and takes responsibility for a series of tasks, depending on individual skills, preferences and links to already completed work. Cooperation between developers for specific tasks completion is also discussed and organised. As always, we favour self-organisation and commitment.

The actual cycle development then starts, based on everybody's tasks. The code is documented and test cases planned. Issues arising during testing are worked on immediately if they can be fixed during the current cycle or are postponed until a forthcoming one. The cycle completes when all tasks are ready or postponed, or when the time allocated to it (say, two weeks) has run out.

When a milestone is reached, results are presented to the Client, who is expected to give feedback. New tasks may arise from the given feedback. SWAP also carries out an internal ("inspect and adapt") review of what was delivered during the cycle. We isolate and document problems or difficulties, make sure we pinpoint what went well and what did not and discuss what we can do to improve our processes.

Cycle kick-off phase
1. Cycle kick-off.
Tasks prioritisation and assignements
Cycle development phase
2. Development is carried out according to the backlog, tests are carried out, issues identified and dealt with
End of cycle quality assurance
3. Quality assurance and deployment.
Client feedback. Inspect and adapt.


When a web site or application is considered ready and approved by the Client, it is deployed into production and made public to its intended target users. Once Deployment is complete, the product moves into a maintenance phase, during which SWAP ensures service continuity and takes appropriate actions in case of temporary problems or bugs submissions (if any).

Do you need a web site for your team or a project?

Contact us

Recent highlights

30 April 2015

The HNS-MS project web site has just been released.

Check it out »

17 March 2015

A new version of our ODAS application is available.

See what's new »

06 February 2015

The FLOAT User Interface has been migrated.

Read more »

25 January 2015

The renewed RV Belgica web site is available; research cruises and programmes for 2015 are online.

Check it out »

20 October 2014

The REMSEM team and its project web sites are now on odnature.naturalsciences.be.

See what's available »

03 October 2014

Learn about COHERENS, our modelling system for shallow waters.

View the COHERENS web site »

17 September 2014

The IBISCA (Investigating the Biodiversity of Soil and Canopy Arthropods) project web site is ready.

Check it out »

9 September 2014

We've migrated a first batch of mumm.ac.be web sites to our OD Nature framework.

See what sites have been migrated »

4 September 2014

The TILES web site opens. The TILES project is funded under the BRAIN-be call ‘Sustainable management of mineral and geological resources’ and coordinated by OD Nature.

Visit the TILES web site »

1 September 2014

We're busy making our production server available. The first web sites will soon become available.