In my recent posts, we’ve looked at several ways of using metrics to help understand the delivery of teams across different aspects. Looking retrospectively is a great way of identifying ways to improve – but you also want to use your data to help you be more proactive and identify ways to better plan and predict the outcomes of your different delivery efforts. In software delivery, speed and quality mean little if outcomes are unpredictable. Leaders and stakeholders need to

In the previous blog post , we looked at the importance of measuring quality and stability. These are important to ensure failures are reduced and system design remains optimal for the user experience. In complex software systems, failure is inevitable; what defines high-performing teams is not whether incidents happen, but how quickly, safely, and confidently they recover. Reliability and recovery metrics measure the resilience of your delivery ecosystem and your organisatio

In my previous blog post , I spoke about the importance of measuring flow metrics and how they can unlock blockers in your development practices and help you deliver more quickly. However, while speed and flow get software into production,  its quality and stability determine whether it stays there . High-performing engineering teams don’t optimise for velocity alone; they balance it with reliability, resilience, and customer trust. Quality and stability metrics reveal how sa

My last two blog posts have focused on the importance of metrics and how to capture your data to create meaningful metrics . I now want ot turn attention to focusing more specifically on the details of the metrics themselves that you should be looking at and why.  If we look at the modern expectations on software delivery, it is often about speed. How fast can you get ot the market, deliver a fix, or deploy a new feature? In software delivery, speed without flow is chaos  -

I started writing in my previous blog post  about the importance of metrics and how they provide detailed insight into the development life cycle and identify key areas for improvement in software delivery for teams. Before delving into the different metrics themselves, though, it’s important to look at how we actually gather the data in the first place. After all, there is no way we can gain insight into our delivery if we don’t have access to the data that provides it. How

The software world may be looking to always deliver innovation and new features faster. However, delivery speed alone is no longer a meaningful indicator of success. Teams are expected to deliver quickly and  safely, sustainably, and predictably. Doing so though is a big challenge for many teams and the key to this improvement is understanding your software well and knowing what is going in in your software delivery process very well. This is where metrics play a critical rol

As the industry continues to rapidly adopt Large Language Models (LLMs) to power chatbots, copilots, search, automation, and decision support, one discipline has emerged as a critical success factor: prompt engineering. While LLMs are incredibly powerful, their outputs are highly sensitive to how they are instructed. The difference between a vague, unreliable response and a precise, trustworthy one often comes down to the quality of the prompt. Soemtihng which is a completely

In my previous post , we explored the big changes required in architecture to make LLMs successful. As those who are familiar with me will know that quality and testing are vital aspects of software architecture to me. So, I feel like I wouldn’t be able to explore the topic of software architecture without aspects of testing and quality. Testing and QA Must Be Built Into Architecture In classical software engineering – at least at a fundamental code level - testing often tend

As I’ve already explored in my previous articles,  LLM-powered applications are having a big impact on the way we think about software development. With this rapid acceleration into AI adoption, many companies and teams are discovering that building applications powered by Large Language Models (LLMs) feels nothing like  building traditional software. The patterns are different, the risks are different, and so are the architectural decisions. LLMs introduce new forms of compl

Large Language Models (LLMs) are only as good as the data that shapes them. Whether you’re fine-tuning a model for domain-specific use or building an LLM-powered application from scratch, data readiness is the single biggest factor influencing performance, reliability, and ethical outcomes. As the saying goes, “garbage in, garbage out”  - but with LLMs, the cost of poor data goes beyond technical glitches; it can lead to bias, misinformation, and loss of trust. In this post,