Thoughts from a Thirsty Bear

I can't quite believe I am writing this in 2026. I originally wrote  a version of this article back in 2016 , 10 years ago! But I am seeing an increasing number of teams overusing their build pipeline again.  I get it. Modern build pipelines now have a huge amount of functionality. They are now far more than simple script runners waiting for a trigger - just look at GitHub Actions, or what you can script these days in GitLab. So it is becoming far more tempting to let critical functionality drift right, and into your pipeline. Builds, publishing scripts, testing etc can all drift right. But don't let it happen! As with all late actions in software, by the time it is in the pipeline it is too late. Pipelines are shared resources, so can be delayed in running. Often the runners are slow, and take time to spin up. And perhaps most importantly,   the pipeline scripting languages are designed to tie you in to a specific vendor . What happens when your pipeline vendor goes out...

What makes a high performing team tick? What is it that takes a team from being medium or low performing into elite performance as defined by DORA? On demand deployments, single figure bug counts, next to no downtime. Having worked in high performing teams, as well as having built a few myself over the years, I feel that I have a unique perspective on what it is that allows a team to work effectively together. The "Secret Sauce". So what's the recipe?  It's...." complicated ". But it looks a bit like this: At the top, unsurprisingly there is Technical Excellence . Team members need to be fully aware of and skilled in the various accepted best-of-breed tools and techniques that are out there. These currently include TDD, BDD, incremental design & architecture, refactoring, pairing/mobbing and so on. No excuses, these are all proven techniques that improve both quality and delivery, and should not be dropped unless there is a provable reason to. Even then ...

Test Driven Development. "TDD". Some love it, some hate it. But many studies now suggest that it is highly effective in reducing bugs (some studies suggest up to 90% of bugs can be eliminated) and improving code structure. But how does it work? Why is there such an effect from such a simple approach?  But before I start I must point out that a lot of what follows is summarising a great talk by Keith Braithwaite called " Measure for Measure: quantifying the effect of TDD " from 2008.  This is just a distillation of his somewhat mathematical analysis and conclusions, simplified, and in my own words aimed at a new audience who may have missed this particular gem. So our story starts with complexity. Cyclometric complexity to be precise. Cyclometric complexity simply explained is a measure of the number of paths through a piece of code. So it depends on the number of decision points - if, while, and switch statements etc. The more paths, the more complex the code is, an...

Working as a jack-of-all-trades agile coach, one of the biggest problems I face is the stagnation of my knowledge. If you do not stretch yourself by working with more knowledgeable people from time to time, you don't develop. You may even go backwards. Prescott's Pickle Principle summarises this as: "Cucumbers get more pickled than brine gets cucumbered" or, put another way, "A small system that tries to change a big system through long and continued contact is more likely to be changed itself" (from Jerry Weinberg's excellent Secrets of Consulting book) Much as I hate to admit it, I am that "small system". So it is healthy and fun to occasionally sit down with like-minded people, and re-baseline your knowledge. That is exactly what I did the other Saturday. I survived a dull and freezing Wimbledon to attend Jason Gorman's " Intensive TDD Workshop " (the one-day super-intensive version of this one ). I won't go i...

I stumbled across a blog post about Scrum's origins on Jeff Sutherland 's blog recently. The whole thing is worth a read in order to get a perspective on where the methodology came from, but especially interesting was the following comment: " Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices... " This fits with my - and others' - experience over the past few years. Scrum, with a few tweaks based on personal experience, provides a good starting point for a lightweight management framework. But that's just it - it's a management framework. You need wrap something to be managed in it. And if that something is a lardy, slow mini-waterfall process then you will simply end up delivering stale garbage more efficiently. XP has the opposite problem. It provides tools and techniques to develop quality software efficiently, bu...