Agile practices

We subscribe to the principles behind the Agile Manifesto and this is reflected in how we work:

• We break down pieces of work into smaller deliverable chunks.
• We consider automated release and test pipelines a critical part of software we deliver, allowing us to release frequently and fearlessly.
• We communicate frequently, but not unnecessarily, both synchronously and asynchronously.
• We aim for flexible arrangements with clients in which we can always address the highest priority work in the face of changing requirements.

Our approach

We approach our engagements and deliverables with an iterative flow through the following phases:

Discovery

The aim of this phase is to gain context of the work, assess the best approach and better predict what lies ahead. The typical artefacts produced at this stage would be:

• Decision logs: Our most frequently produced documentation, underpinning our technical decision making.
• Technical documentation: Mostly applicable at the beginning of engagements, for projects that do not already have architecture diagrams or a documented data model. Artefacts are considered "living documents" and will be updated as the software evolves. In our typical work, documentation is informed by the Decision Logs.
• Risk register: As we gain understanding of a project, we may produce a technical risk register to manage technical debt and other technical risks. This is a living document, with the initial version produced at the beginning of an engagement. This supports conversations with clients about managing technical risks and prioritising their mitigation (or not, if the risk appetite is high).

Delivery

In this phase we deliver the work agreed in the Discovery phase to the standards defined in our Definition of done.

While we take reasonable measures to manage uncertainty (e.g. by breaking down work and undertaking Discovery), our agile practices allow us to change course in the face of changing requirements, priorities, or uncovering "unknown unknowns".

Reflection and planning

We demonstrate functionality and gather feedback continuously as we deliver work, however this final phase allows for a retrospective of the outcome and identifying process improvements.

It is also when upcoming work can be prioritised and planned, kicking off the Discovery phase of the next iteration.

Decision making

Decisions are made daily about architecture, implementation, future direction, technology choices, etc. We believe that capturing these in a lightweight and standardised format has benefits, both to support better decisions and as a reference. For this we use Decision Logs, an iteration on Requests for comment (RFCs) and Architectural decision records (ADRs). A decision log captures:

• Context: Why is the decision important? This sets out the criteria for the decision.
• Options: What are the options to decide between? This could range from architecture and technology choices to binary choices such as whether something needs to be done or not. This section records the evaluation of the available options against the criteria defined in "Context".
• Decision: Which option was chosen? This follows a discussion with the wider team or stakeholders to make the choice in light of the appraisal.

Definition of done

We consider work "done" when it:

• Satisfies the user or acceptance criteria defined.
• Passes quality assurance.
• Is documented, if applicable.
• Is deployed to all environments and released to users.

Technical conventions

We use standards, such as conventional commits and conventional comments with our code. They enable clearer communication and automation.

We believe in the usefulness of code linters and formatters and work with tools that do this automatically and verify adherence in CI pipelines.

We have a preference to work with statically typed languages, as a means for quality assurance and documentation it provides.