Engineering Change Part 5: Mastering the engineering development cycle

This five-part series explores how composable architecture, emerging technologies, and a collaborative engineering culture drive meaningful transformation. It’s a practical guide for organisations looking to modernise legacy systems, unlock agility, and build future-ready digital solutions.

This is part five: In it, Declan details Inviqa’s sprint-based development rhythm, from planning to deployment, with quality and transparency at the core.

In a snapshot:

We work in two-week sprints with collaborative planning and refinement, and:
•    CI/CD pipelines ensure fast, safe delivery
•    Testing, code reviews, and security scans are built into every step
•    Developers own what they build — from code to production monitoring

Click on the links to read part one, part two, part three, or part four.

Here's what a typical sprint format would look like, with your overall project split into the number of sprints we think will take to complete it.

1.    Planning & Refinement: 

We start each sprint by understanding and refining the next set of tasks together with you. The team discusses requirements and clarifies any ambiguities - if something isn’t clear, we encourage everyone to ask questions (chances are someone else is wondering the same thing). We break down features into small, manageable chunks that can be built, tested, and deployed independently. Anything estimated to take more than a few days is likely too big and gets split up further or put behind a feature flag for incremental release. 

2.    Prioritisation & Task Assignment: 

The product owner (or project lead) will prioritise the backlog - making sure that the highest-value and most critical items are addressed first. Developers then pull the next task from the top of the list, rather than having work simply handed to them. Before starting, the developer checks in with QA and the Scrum Master (or project manager) to ensure everyone’s on the same page about the acceptance criteria and dependencies. Then, it’s time to dive in and start coding. 

3.    Branches & Commits: 

We follow Git branching strategies that keep our main code line stable. Typically, all new code is developed on feature branches (named like feature/1234-short-description or bugfix/issue-id-description) off the main branch. This naming convention isn’t just for humans - our CI/CD pipelines often use branch naming to decide what tests to run or where to deploy. We also believe in clean commit history: commit messages should be descriptive (no one enjoys debugging through a series of “fixed stuff” or “oops” commits). A tidy commit history makes code reviews and future troubleshooting much easier. 

4.    Testing Early & Often: 

Quality is built in from the start. Developers write unit tests for any new logic to ensure the code does what it’s supposed to in isolation. We also write integration tests to verify that our services can talk to databases, third-party APIs, and other systems correctly. As we complete features, we often create end-to-end tests that simulate a user clicking through the application to ensure everything works together as a whole. We don’t stop at functional tests either - as we build, we think ahead about what metrics and alerts we’ll need in production. By planning for monitoring early, we can deploy new features with the confidence that we’ll know if something goes wrong. 

5.    Code Reviews & Security Scans: 

Every change goes through a peer review process. We open a pull request for each feature or fix, no matter how small. Keeping PRs small means, they’re quicker to review and integrate. During reviews, we give constructive feedback and always focus on the code, not the person - it’s about making the product better and sharing knowledge. Alongside human reviews, our automated security scanners run on the code and any new dependencies. If a security issue is flagged (say a new library version has a known vulnerability), we address it then and there. We believe that catching and fixing issues early is far easier than after code has been merged.

6.    Continuous Integration & Deployment: 

Our CI pipeline runs on every push to a feature branch. It compiles the code, runs tests, and performs static analysis and security checks. Only if the pipeline is green do we consider merging. Once changes are merged to the main branch, this triggers a production build. We typically have an automated deployment flow: merging to main might deploy to a staging or UAT (User Acceptance Testing) environment automatically. With a quick smoke test and stakeholder sign-off, that same pipeline can promote the build to production at the push of a button (often using infrastructure-as-code to ensure the deployment is identical to staging). We never leave a broken build unattended - if the pipeline goes red, the team treats it as an “all hands-on deck” situation to fix the build, because a failing build means we’re not delivering value. 

7.    QA, Design, and PO Sign-off:

Quality Assurance and design/usability experts are involved from the very start of each story. Testers and developers work together so that test cases and edge scenarios are considered while the code is being written, not after. Our designers ensure that what we build matches the intended user experience and visual design down to the pixel. When a feature is complete, we demo it and the Product Owner (or client stakeholder) gives the final thumbs-up that it meets the need. Only then do we consider it “done done” and merge it for release.

8.    Release & Ownership: 

When your feature goes live, the work isn’t quite over - we believe in owning what we build. The developer (or team) that shipped the feature will verify the deployment and keep an eye on the relevant dashboards or alerts afterward to ensure everything is behaving as expected in production. If an issue arises, we react quickly to fix it and communicate transparently. This ownership mindset ensures accountability and maintains trust with you as the stakeholder and with your end users. 

Our sprint-based approach allows for regular feedback, continuous improvement, and a shared sense of ownership. But we appreciate it’s not one-size-fits-all. If you would prefer a Waterfall-style delivery, a DevOps or DevSecOps emphasis, or something entirely bespoke, we can adapt our ways or working to meet your needs.

Ultimately, our goal is to build great software together, with transparency, trust, and technical excellence at every step.

As this series has shown, meaningful transformation isn’t simply a collection of technologies - it’s the result of combining the right people, tools, and practices to deliver meaningful outcomes. 

At Inviqa, we focus on pragmatic, reliable solutions that balance speed, quality, and long-term maintainability, embracing composable architecture and emerging technologies to deliver solutions that last. 

We adopt sensible defaults like Next.js, TypeScript, and AWS ECS because they’ve proven to be robust, scalable, and developer-friendly. But we also maintain a broad and adaptable skill set, allowing us to tailor our approach to the unique challenges and goals of each project. Underpinning our work is a disciplined development cycle, backed by strong practices in testing, DevOps, and security. This enables us to move quickly without sacrificing reliability or maintainability. 

Most importantly, we care deeply about how we work - both with each other, and with our clients. This means open communication, thoughtful planning, and a shared commitment to getting things right. When you work with Inviqa, your project isn’t just in capable hands - it’s in trusted ones.