All software produced at Omni is developed, designed, tested and implemented with a commitment to Agile - a process which we believe helps people make better software for other people.

We genuinely believe that working to a fixed-scope in the context of software development is not just a rejection of the very need for allowing for change, but it is actually harmful to the quality of the end product.

Since adopting Agile in its fullest sense, we’ve seen complex projects develop in ways which have delighted end-users, clients and even ourselves, and which would have simply not been possible before.

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

How We've Implemented the Agile Manifesto

We’ve hired - and continue to hire - developers who can work well as a team, communicate efficiently, and value different approaches and opinions.

Where we can automate a given piece of work, we build a tool or a service to automate it to reduce developer burden. Likewise where we need to define a process to help us all work more efficiently, we do so collaboratively.

At the beginning of any of our projects - we define the most appropriate methodology and then implement it.

After all - these methodologies exist to serve us and are tools for a particular job. Whilst we may have a hammer in our toolbox - we certainly don’t believe every situation is a nail which calls for one!

We build fast, test our assumptions, and release often. We consider a failed, cheap test to be of far more value than a comprehensive document describing yet-to-be-written code. We start with the fewest assumptions necessary to write the least code, and then release it into the wild to be tested. That way we can quickly establish what, and the rest is discarded and learnt from. And at no point has the project haemorrhaged cash, time, or morale.

Our client-facing agreements are as light as possible to allow everybody to collaborate safely, efficiently and in earnest, whilst accommodating the potential need for change. We implement Agile support retainers where possible, and incorporate requirements gathering processes with optional break clauses where not. Our key aim is to build a backlog of intended features as quickly as possible so that we can get down to writing code and testing these assumptions in the wild. As ultimately - what is more important, a lengthy specification or working software?

All of this allows us to truly respond to change as effortlessly as change itself occurs. For there is no real consistency - change is ever present. Rigidity in planning software only leads to software that is too rigid to accept change. Instead, we can embrace the certainty of change from the start, and create truly great software.