Software delivery in 2026 is no longer just about shipping features quickly—it’s about delivering continuous value safely, predictably, and at scale . The best-performing organisations treat delivery as a product capability, not just an engineering process. A good software delivery model today blends DevOps, platform engineering, automation, and strong product thinking  to create a system where teams can ship changes frequently without sacrificing quality or stability. The Ev

In modern software delivery, incidents are inevitable. Distributed systems are complex, dependencies are layered, and even the most mature teams will eventually face outages, degradations, or unexpected behaviour in production. What matters most is not whether incidents occur, but how organisations learn from them . Post-Incident Reviews (PIRs)—sometimes called postmortems—are widely adopted to extract learning and improve resilience. Yet in many organisations, PIRs drift int

The role of the Delivery Leader has always lived at a crossroad of execution, coordination, and accountability. But in today’s software engineering landscape—defined by AI acceleration, platform engineering, distributed teams, and continuous product discovery—that crossroad is shifting. Delivery leadership is no longer about managing timelines. It’s about enabling outcomes. Over the next few years, Delivery Managers and Delivery Leaders will need to evolve from operational ov

I wanted to follow up on a previous post pretty quickly. A post about embedding AI in testing where it really will add value. That post can be found here Exploratory testing thrives on human curiosity. Unlike scripted testing, it allows testers to interact with software the way real users do—navigating unpredictable paths, asking “what happens if…?”, and uncovering issues that structured test cases are likely going to miss. AI has accelerated in many areas of software testin

AI is rapidly appearing in every corner of software development, and testing is no exception. From AI-generated test cases to self-healing automation and defect prediction, there’s no shortage of tools promising to revolutionise testing. But as with any emerging technology, the key question isn’t “Where can we use AI?” It’s “Where does AI actually add value?” Embedding AI into software testing sensibly requires understanding both its strengths and its limitations. Used correc

For years, we’ve been told to follow the “Test Pyramid.” Lots of unit tests. Fewer integration tests. Even fewer end-to-end tests. It’s been presented as an almost unquestionable truth - a universal law of good engineering. But what if the test pyramid was never a law? What if it is a simplification that became dogma? And more importantly: What testing actually matters? Where the Test Pyramid Came From The concept popularised by Mike Cohn in Succeeding with Agile  was meant t

In a previous post ( Here ), I explored continuous flow in delivery - the belief that it’s better to continually add value than to follow a rigid methodology that slowly drifts away from the outcomes it was meant to achieve. Now I want to take that thinking one step further using Scrum  as an example. Not because Scrum is flawed. But because the way we use it and other methodologies often is. Scrum Was Never Meant to Be a Cage Scrum is a lightweight framework designed to help

Decommissioning a platform is rarely just a technical decision. It’s emotional. For many teams, the platform represents years of effort, identity, late nights, launches, firefighting, and pride. When leadership decides to start looking at decommissioning to consolidate and reduce costs, the announcement can feel less like a strategy and more like a loss. If you’re leading a team through this transition, your primary job is no longer product delivery. It’s expectation manageme

In software delivery, we often talk about speed. We talk about efficiency. We talk about agility. But what we’re really chasing - whether we realise it or not - is flow . Flow is the state where work moves smoothly from idea to value. Where teams aren’t blocked by unnecessary friction. Where progress feels natural rather than forced. Where delivery becomes a continuous, sustainable rhythm instead of a series of stressful pushes. Agile as a Tool, Not a Rulebook Agile methodolo

Change Advisory Boards (CABs) were created for a good reason: to reduce risk, improve visibility, and protect critical services. In the right context, they still play an important role. The problem isn’t that CAB exists. The problem is when CAB becomes the default response to all change , regardless of risk, frequency, or impact. When that happens, CAB stops protecting delivery and starts blocking it. Why CAB Was Introduced in the First Place Historically, changes were: Infre

Practical strategies for SLT and Product Leaders on cost optimisation! In an environment of tightening budgets, increasing cloud spend, and growing customer expectations, cost optimisation in software and platform delivery has become a strategic priority rather than just an operational concern. For Senior Leadership Teams (SLT) and Product Managers, the challenge is not simply to reduce costs, but to optimise spend while maintaining delivery velocity, quality, and business va

Most organisations don’t struggle with measurement because they lack data. They struggle because they measure the wrong things , report them in the wrong way, and mistake activity for progress. Outcomes-based delivery, supported by well-designed OKRs, promises focus and alignment. But when implemented poorly, OKRs quickly become another reporting burden - detached from real decision-making and day-to-day work. Measuring outcomes effectively is not about perfect metrics. It’s

When people talk about AI in software delivery, the conversation often gravitates toward code generation, test automation, or developer productivity. While these are valuable, they represent only a fraction of the reality. As delivery managers know all too well, development is just a small part of the software delivery lifecycle . The real complexity lies in planning, coordination, risk management, communication, governance, and continuous improvement. This is where AI has th

Artificial Intelligence is no longer a distant concept or a specialist tool hidden inside research labs. In How AI Will Change Your Life , futurist Patrick Dixon argues that AI is becoming a foundational force , reshaping how we work, travel, communicate, and govern societies. While the book explores many industries and ethical questions, this article focuses on six areas where Dixon’s insights are particularly immediate and practical: software development, marketing, travel,

The start of a new project is a critical moment. It sets the tone for how a team collaborates, makes decisions, and delivers value. Too often, however, teams begin their journey burdened with predefined processes, packed calendars, and rigid expectations - before they’ve even had a chance to understand the problem they’re solving. High-performing teams are not created by ceremony-heavy playbooks. They are built through trust, autonomy, and intentional structure , introduced a

It's been a good number of years since I made the conscious decision to move into a delivery role. I thought it was a good time to reflect on it. My move from QA/Test Engineering into Delivery Management wasn’t a departure from quality - it was an expansion of how I wanted to influence it. For a long time, my focus was clear: protecting customers from poor experiences, ensuring systems behaved as expected, and helping teams ship software they could be proud of. Quality was ta

If you work in Agile, DevOps, or platform teams, heated debates are part of the job. Discussions about reliability versus speed, standardisation versus autonomy, or short-term delivery versus long-term sustainability can quickly become intense - especially when production incidents, delivery pressure, or organisational dependencies are involved. These debates aren’t signs of dysfunction. They are signs that people care deeply about building systems that work. The challenge is

Discovery is often misunderstood. Too short, and it becomes guesswork. Too long, and it turns into analysis overload. In modern software delivery, a good discovery phase doesn’t try to design the solution - it creates the conditions and boundaries for a successful delivery to operate in. I'm going to outline what I believe are the key parts of an effective discovery for a modern-day software delivery programme of work. 1. A Clear Problem Statement Discovery should start with

In the world of IT contracting, expectations are clear and often uncompromising. Contractors are brought in as experts: people who can hit the ground running, deliver against a specific remit, and add value from day one. Against this backdrop, the idea of coaching and mentoring can feel awkward, even risky. Why would an “expert” need mentoring? And does offering or receiving it blur lines around independence, especially in an IR35-sensitive environment? Despite these tensions

Have you ever wondered whether the way you make a living and the hobbies you enjoy could complement each other? I work in software delivery, but my camera is never too far away! If you’re a software delivery manager, your world revolves around alignment, clarity, flow efficiency, and helping teams deliver valuable outcomes predictably. But sometimes, the best insights don't come from frameworks, certifications, or delivery models—they come from unexpected places. For me, one