Our site uses cookies. To find out what cookies we use and why we use them click here. If you carry on using our site we will assume you consent to us using cookies in this way.

Project ManagementEmpowering change in an interactive
and flexible manner

I won't lie - This is a marketing email..

read our blog

Call 0033 6 46 18 13 74

Application Development Methodology

Helix uses the Agile programming methodology for project development with a few variations to suit the company resources.

The Agile Manifesto: Principles

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time-scale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity is the art of maximising the amount of work not done is essential.
  • The best architectures, requirements, and designs emerge from self-organising teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Agile Planning

The Agile programming methodology is divided into 4 activities and deployed with an iterative style, Planning, design, coding and testing. These steps are revisited when needed and according to the schedule.

User Stories

User stories are a way of capturing the desired process / functionality in easy to understand format. This is similar to requirements gathering in traditional development methodologies, but it differs in that technical details are omitted and work to be performed is described in plain English, broken out into two- to three-week sections. Each user story is written onto an index card and used to plan releases.


A release consists of user stories grouped together based on dependencies and business need. Agile programming releases are not partial deployments but rather represent completed, logically grouped portions of functionality. Scope or duration can determine a release, and functionality is chosen by common sense and priority.

Each release comprises several iterations and is largely determined at the beginning of the project. Releases are organised by grouping the user story index cards together.

Just-in-time planning

Once there is an idea of the releases, a iteration length is determined. An iteration should be one to three weeks in length, and there should be three or four iterations per release.

Iterations are defined by selecting the most important user stories and breaking them down into programming tasks. The client should be involved in deciding what task has the highest priority, and are planned to complete it first.

Designing the solution

Designing the solution with the agile methodology is simple. It's spread out over the course of development, rather than being completed up front.


As the project progresses, Code is revisited to clean up and consolidate functionality. This is called refactoring, and it allows the system architecture to develop logically and organically. Every iteration includes time for restructuring.

Spike solution

When a tough problem is encounter that lacks an immediately apparent solution, a spike solution is created. This is where different approaches are tried in code to make the correct solution more apparent.

Client contact

Frequent contact with the client is crucial for the deferred planning of this methodology. Not only does frequent contact help clarify details and prioritise tasks, but it's also a great management tool giving the client confidence in delivery and abreast of progress.

Testing framework

Unit tests are created before writing code and incorporated into a testing framework. Where suitable, preliminary interfaces with debug flags are used for back-end functionality testing. Code enhancements and additions are completed in a separate iteration, facilitating quality assurance.



Form Fields