Drupal Architecture.
Drupal Development.
Drupal Support.
Drupal Architecture. Drupal Development. Drupal Support.

Our Approach to Development

We work using development processes commonly referred to as “Agile” development. This means that we stay flexible and open to changes in requirements and priorities as knowledge increases and boundaries shift. This ensures that we are able to best meet your goals as they evolve and adapt.

Discussion items.
We use Pivotal Tracker extensively to capture all discussions as these can form a valuable reference point for members of the development team who may not have been present at the time the discussions took place.

Prioritised and sized User Stories.
User stories (also referred to as Product Backlog Items or PBIs) form the bulk of the development project outline. These stories define the features that are about to be developed in enough detail to enable our team to be productive. By sizing the stories relative to one another, we can quickly see which stories are larger and which are smaller, and then use this information to help decide on the priorities.

Well defined Features / Requirements.
A product backlog is something that constantly evolves throughout the life of the project. The initial product backlog that we have created and supplied as part of this proposal is only the beginning. These are good to give a sense of project scope, but not so good for a team of developers who need more information than that to be able to begin development. Through the discovery process we begin building out these user stories in more detail, adding task lists, acceptance criteria, and detailed notes to help the team understand the what, the why, and the how.

Opportunities to deploy.
The agile process is an iterative one, with a goal of delivering real value in the form of potentially releasable software at the end of every sprint. Sometimes this will be deployed to staging or internal environments for internal review, other times we will aim to deploy to production. As we go through the discovery process we may try to identify ways to break the project up into phases such that specific targets can be set for the deployment of certain functionality.

Client Involvement

It is vitally important that clients get involved with the project from an early stage. Our experience has shown that sandboxing ourselves from our clients until the end of the project would be a huge mistake. As the product starts to materialize and our clients begin to see their ideas turning into a product that they can actually interact with, new ideas inevitably will come to light, and old ideas may become obsolete. By involving our clients from an early stage and throughout the project, we can adapt our development approach and re-prioritize without straying off track.

Release Cycle and Milestones

The product release cycle is typically aligned with the sprints. That is to say that at the end of two or three week sprint, all work completed in that sprint will be deployed to a primary staging server, which our clients have access to. This means that you can interact with the product as it evolves. Once the project has been further broken down, we will look to identify achievable milestones where official releases will be made – often, these follow traditional software milestones such as Alpha, Beta, Release Candidate, and Final release.