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

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! At first glance, software delivery and photography seem like two completely different worlds—one driven by logic, engineering, and systems; the other by creativity, emotion, and visual storytelling. But look a little closer, and the overlap is evident. In fact, many photographers would make excellent

Over the last 12 months, we have seen significant advances in AI technology across many areas, including AI assistants (ChatGPT, Claude, Gemini), Image Generation (GPT-4, Midjourney), Writing tools (Rytr, Sudowrite), and Marketing (AdCreative, AirOps), among others. It's grabbed the attention of many global leaders. I've worked in the IT industry for just short of 20 years, and like anyone else, I would probably say things are constantly changing. Technology moves fast. Among

Let's take a look at some sound engineering principles. Pairing Vs. Code reviews:  Try to avoid treating code reviews as post-development “barriers”. TDD - Tests should be written both by the Developer and QA (It's also not uncommon for others within the team to be involved), preferably in conjunction with each other, throughout the development of functionality - Testing is never an afterthought! Regular, Incremental Delivery – Start by building the smallest unit of value po

End-to-end (E2E) testing can quickly become an ambiguous term, especially when developing microservices. E2E testing in the context of integration between multiple microservices is a bit of an anti-pattern. There is still considerable demand for creating large numbers of E2E regression tests. In a monolithic world, this is without a doubt extremely important when the entire system's function is a single application as an individual, autonomous unit. We have to accept that one

An organisation that I have worked with recently are going through a significant digital transformation. For the organisation, this is an entirely new way of thinking. As a team, we want to revolutionise their ways of working by using new, fast, and frequently changing digital technologies to solve their problems. I have been looking into creating an overarching Testing Strategy. A lot of this isn't information that's uncommon, but I thought it would be helpful to those start