How We Work

Our expertise is based on the way we develop software to bring ideas to market. We focus on practices that unlock a pipeline of ideas, in a way that allows those ideas to be delivered incrementally and to be validated by real users.
We couple rapid development practises with a mindset of doing just enough to bring an idea to market.

By avoiding over-investment it is easier to adopt a learn-fast model for delivering software.
Of the many things we have learned along the way, we know there is no magic bullet. Delivering the right software early and often requires a focus on people, processes, and technologies used.

Our high performing teams are typically small in size, stocked with skilled individuals, and have developed a rapport through working together over an extended period.

We prefer smaller, self-organising teams for their effectiveness. Simply put, we believe our developers know best how to solve the problems they encounter on a daily basis. In a small team communication is straightforward and everyone has a voice – decisions get made quickly and things get done.

There was a time when we ran software projects using methodologies better suited to engineering than software development. We focussed on hierarchies, division of work, specialisation, and detailed plans. For us, this approach was simply not effective – it didn’t cater for the frequent changes we encountered.
These days our work involves creating software for new ideas and complex systems. As such, we find it is better suited to management techniques that cater to adaptation and emergent behaviour. Increasingly, we are drawn to using trials, experiments, discussion, and self-organising teams.

When working on new ideas we like to test them frequently – getting feedback from users, quickly. Successful ideas can then be further invested in, while duds can be discarded with minimal fuss.

We use Agile/Lean methodologies that promote a short build-measure-learn cycle. This allows us to quickly verify hypotheses, correct, and evolve our work. This “learn-fast” model of software development helps us consistently deliver useful software.
We opt for tools and techniques that support deploying working software earlier and more frequently than has been possible in the past. The notion of continuous delivery – deploying software as a progression of small enhancements – has changed everything about the way we work except the art of writing code itself.
Continuous delivery is largely underpinned by automation of the build and deployment pipeline in order to streamline the validation of changes before they are released to users.

It requires not only changes to the way we architect, test, and deploy software, but also the way work is initiated and funded. In the world of continuous delivery software systems emerge from the delivery of small feature-based components (or microservices). These components are woven together to create a flexible, seamless fabric that represents the current state of an enterprise’s interface with its many stakeholders.

A continuous delivery process supports the both the release of features frequently and the ability to run experiments – deploying variations of the same feature to garner user feedback by measuring user interaction.

We architect for flexibility, allowing for the inevitable changes our software will undergo as we deliver new features.

A microservices architecture provides us a way to evolve an application, one feature at a time. It allows us to deliver and support features independently of each other, and, by extension, avoid the problems caused by a monolithic architecture.

Microservices are the ideal complement to continuous delivery – applications can be delivered incrementally, service by service.