This article summarises insights originally reported by Computing from their DevOps Summit, featuring practitioners from Paddy Power Betfair and LV=.
Stop Over-Planning and Start Doing
One of the most common reasons DevOps transformations stall is analysis paralysis — teams spend months building roadmaps, gaining buy-in, and defining processes before a single thing changes. According to practitioners who have actually done it, that is the wrong approach.
Steven Armstrong, principal DevOps automation engineer at Paddy Power Betfair, speaking at Computing’s DevOps Summit, was direct when asked how he launched his organisation’s DevOps initiative: “We were just able to do it.”
Armstrong’s advice: identify a genuine pain point — a single point of failure, a fragile deployment pipeline, a manual process that blocks releases — and start there. “Pick something like that, the low-hanging fruit, and go for it. Pick something and just start on it; don’t spend a hideous amount of time in planning,” he said.
What “Low-Hanging Fruit” Actually Means in Practice
The low-hanging fruit principle is about identifying work that is:
- High-pain: Something that visibly slows the team down or causes repeated incidents.
- Self-contained: A change that can be made without requiring a full organisational restructure first.
- Demonstrable: Something that, once improved, produces a measurable outcome stakeholders can see.
Armstrong’s team targeted single points of failure in a legacy database architecture under their old system. Fixing a concrete reliability problem gave the team a visible win and built momentum for broader change — without requiring months of upfront justification.
This approach also reduces political risk. A small, targeted improvement is easier to fund, easier to execute, and easier to learn from than a sweeping transformation programme.
Shift Left: Embed QA in the Development Team
Beyond choosing where to start, Armstrong highlighted a structural change that had a significant impact at Paddy Power Betfair: embedding Quality Assurance (QA) engineers directly inside development teams, rather than maintaining a separate QA department that reacts to completed code.
This practice — commonly called shifting left — means quality is considered at the earliest stages of the development cycle, not bolted on at the end.
“You don’t want a situation where you have QA reacting to development changes. Then testing runs will fail because the devs introduced a new GUI or something. So we moved teams together and then when the devs were developing code, QA were embedded there to help at the point when they were defining the user story. So you’re writing the test criteria along with the requirements and design. That’s really important, because you can’t have siloed departments that are purely reactive any more.”
Steven Armstrong, Principal DevOps Automation Engineer, Paddy Power Betfair
In practical terms, this means QA engineers participate in story refinement sessions, contribute to acceptance criteria before a line of code is written, and write automated tests in parallel with development — not after a feature is declared “done” by the developer.
Separate QA Teams Are an Obstacle to DevOps Culture
Gordon Gracie, development team lead at insurer LV=, went further, arguing that the very existence of a separate QA function is structurally incompatible with a DevOps model.
“The biggest injustice you can have today is the idea of QA people in a separate role. Software engineers want to write great code. If the engineer is obsessed with quality, they’re also obsessed with testing that quality. Some people are experts in testing, but the idea of separate teams doing that work needs to be broken down. If you have that set up, you’re creating a culture that stops your engineers moving to a DevOps model.”
Gordon Gracie, Development Team Lead, LV=
Gracie’s point is not that testing expertise is irrelevant — it clearly is not. The concern is that when testing is institutionally separated from development, it creates a handoff boundary. That boundary introduces delays, miscommunication, and a diffusion of ownership over quality. Engineers pass code over a wall; testers find problems; code comes back. This cycle is fundamentally at odds with the fast-feedback loops that DevOps depends on.
Key Takeaways for Teams Starting a DevOps Initiative
- Start with a real problem, not a framework. Find something that is causing pain right now — a flaky deployment, a manual handoff, a reliability bottleneck — and fix it. Don’t wait until you have a complete DevOps strategy.
- Keep the first project small and visible. Early wins build trust and funding for larger changes. A contained improvement with a clear before-and-after metric is more valuable than a sprawling transformation with unclear outcomes.
- Embed QA in the team from day one. Test criteria should be written alongside requirements, not after the code is complete. This is the practical meaning of shifting left.
- Break down silos structurally, not just culturally. Telling separate teams to “collaborate more” rarely works. Physically or organisationally merging QA into delivery teams changes the incentives and the feedback loops.
- Treat quality as an engineering responsibility. Testing expertise is valuable, but responsibility for quality should be shared across the whole team, not delegated to a separate function.
The Broader Lesson
DevOps transformations fail most often not because the technology is wrong, but because organisations wait for conditions to be perfect before they begin. They wait for full executive buy-in, a complete toolchain decision, or an agreed operating model. Meanwhile, the problems that DevOps is supposed to solve continue to compound.
The practitioners at Computing’s DevOps Summit offered a simpler operating principle: find the thing that hurts most, fix that thing, learn from it, and repeat. That is, in essence, what DevOps looks like in practice — not a destination arrived at through planning, but a habit built through iteration.