Revisiting @stevesmithtech.bsky.social's Continuous Delivery patterns. some good patterns to abstract away app technology from the pipeline www.stevesmith.tech/blog/tag/pat...

And I can fit XP inside pretty much any less iterative methodology. Sure, we'll give you a detailed architecture plan. * starts reverse-engineering releases into a UML model *

Two reasons: 1. I didn't want to spend 2-3 decades sitting in meetings, and b. It's in the inner feedback loops when changes tend to have the most leverage. I can "Agile" your team at a fraction of the cost of trying to "Agile" your boss.

But, compliance! Somehow, a welcome justification for all the superfluous gates in our software delivery process, and to embarrassingly uphold the unreasonable delays. (1/3)

I will be speaking at @fosdem.org in the Testing and Continuous Delivery dev room next weekend. Non-Blocking Continuous Code Reviews at 12:05 on Sunday First time speaking at FOSDEM fosdem.org/2026/schedul...

Published: Coping Mechanisms for Introverts thinkinglabs.io/articles/202...

A while back, someone attempted to make the case for code reviews as a better alternative to sharing knowledge over Pair Programming. The main arguments put forward were economics, poor feedback and least-common-denominator performance. Let me debunk that 🚀 thinkinglabs.io/articles/202...

Published: What is Continuous Delivery? It takes nine principles, one heuristic, three foundations, one pattern and three practices to practice truly Continuous Delivery. thinkinglabs.io/articles/202...

Let's talk about failed IT projects ... Remember how agile methodologies were introduced to exactly counter that. You would think that failed IT projects are a thing of the past. Hell not! Good article on the state of IT in 2025. It's not pretty! (credit DORA) spectrum.ieee.org/it-managemen...

If you asked me to characterise software development in its essence, I'd say it's a process of reducing uncertainty. Otherwise known as "learning". codemanship.wordpress.com/2025/11/28/w...

The art and skills for delivering software in much more smaller incremental steps were lost with the global adoption of Pull Requests.

There’s also the other way around, where management says they tried OKRs and found that they ‘don’t work’, so you can’t introduce them. So you agree, and instead talk to the team about your ‘goals’ and ‘success measures’ 😶

OKRs is like Continuous Integration and Continuous Delivery. Everybody says they do it. But in reality don’t🤷

I’ve heard @tdpauw.bsky.social talk about this before, and it clicked instantly — totally agree. But every time I share this idea, people look at me like I’ve just declared code reviews are a myth from ancient folklore. 😂

Slack channels are a good indicator of silos in an organisation 🤷

“Anyone who believes code reviews catch bugs, believes in fairytales” Automated and exploratory tests catches bugs… Code reviews help lower the risk that we release low quality code. @tdpauw.bsky.social #agilecam

What code reviews should not be: * Ways to exercise power - it should be true peer reviews * Done by seniors missing mentoring skills * blaming or harming * a miserable experience * gate keeping (gates introduce delays) * a must @tdpauw.bsky.social #agilecam

It was two days of interesting talks and workshops, where three stood out to me: First was “Non-blocking continuous code-reviews, a case story” by @tdpauw.bsky.social I always enjoy hearing Thierry’s talks. He provides great insight in various ways of getting higher quality code :)

I answered over @ sw-development-is.social/@TheTravelle... ➙ For more about trunk-based dev, I suggest @tdpauw.bsky.social's article thinkinglabs.io/articles/2025/… He wrote more great articles about the topic. There's even a VCS that doesn't use branches: Jujutsu ➙ jj-vcs.github.io/jj/latest/

Nudging is not going to fix our lack of understanding basic principles. #justsaying 🤷

Last week I spoke at Agile Cambridge, and it was great being back. I arrived in 18 degrees so started with a walk on campus :) As always the people and the discussions were the best parts. Some people I had not seen since before the pandemic, some were new, and some I got closer to 💕 #agilecam

We now have a generation of developers who’ve never experienced an alternative to blocking code reviews. But pull requests aren’t anyone’s security blanket, and it will only take a new fashion to change this. Thierry’s excellent presentation is a call to action for the trend setters.

The slide deck of my session Non-Blocking Continuous Code Reviews - a Case Study Thank you for all the interesting questions and the lovely feedback. I’m truly grateful for that ☺️ #agilecam thinkinglabs.io/talks/2024/0...

Someone just told me I am an engaging speaker. Really ⁉️ 😳 But thank you, you just made my day ☺️

Software development may be a foreign country for the business. To gain trust we need accountability. — @jamesshore.bsky.social #agilecam

Better to have no estimates than wrong estimates. — @jamesshore.bsky.social #agilecam

It is still guesses at the end of the day. But it is better to have some model than a perfect model. — @jamesshore.bsky.social #agilecam

eXtreme Programming is a foreign country. We do things differently! — @jamesshore.bsky.social #agilecam

People think software development is about writing code. It is not! It is about: Communication Collaboration Simplicity Courage Respect -- XP Values, @kentbeck.com @jamesshore.bsky.social #agilecam

This is the article behind the talk that @tdpauw.bsky.social delivered just now: thinkinglabs.io/articles/202... #agilecam

I always enjoy hearing @tdpauw.bsky.social talk :) This time he is talking about non-blocking code reviews. He always provides great insight on technical topics and new ways to get better code quality :) #agilecam

Published: A Tester's Growth-Path to Test Automation At one client, the topic of how a growth path for Testers in Test Automation would look in their QA Community of Practice. That triggered me to ask that question in the wild. Here's the result. thinkinglabs.io/articles/202...

No, people will sit idly because they are intrinsically lazy. McGregor wrote about this in the 70s... That is, they indeed are if you treat them as if they were.

Solo work is often silo work

Our Work in Progress (WIP) should be at least equal to the number of team members. If it is less, it means someone is idle ... So what? That so-called idle person might be helping out someone else ...

Published another update to: So, Yes, Trunk-Based Development! Now what? Added the questions: - How to maintain multiple versions? - Can we use branches? thinkinglabs.io/articles/202...

Semantic Versioning and SaaS So, Semantic Versioning is absolutely important when delivering a library that others rely on. It is downright unimportant when we are operating a SaaS product. Which version number is deployed does not matter.

Published an update to: So, Yes, Trunk-based Development! Now What? Added the missing reference to the Walking Skeleton when implementing large changes. Thanks to Steve Hallman for bringing that to my attention 🫶 thinkinglabs.io/articles/202...

How many environments should we have? In my humble career, I have seen a whole range of environments used, going from two to ... five/six 😳 The orgs having only two environments are generally doing better 🤷 I guess the fewer environments, the more attention to quality. MTTR will be reduced too

X: When deploying in test things break for other teams. Y: The problem is we only have shared test environments. The problem is not shared test environments. Production is messy, anyway. If we cannot handle messiness in test, production will be downright chaos. It is a skills and practice problem.

Released @thinkinglabs/aws-iam-policy v3.2.1 A TypeScript DSL for handling AWS IAM Policy documents programmatically instead of using JSON strings. Specifically designed to be used with the Pulumi provisioning tool. www.npmjs.com/package/@thi...

Published: So, Yes, Trunk-based Development! Now What? We are sold on the idea of practising trunk-based development. However, all the articles we read on the topic leave us with tons of questions. This is an attempt to answer these questions. thinkinglabs.io/articles/202...

Continuous Integration does not require executing the whole damn automation test suite all the time at every integration. Of course, in that case, it is hard to have fast builds.

Today, pushing TBD could be considered to be career limiting. I've been thinking about that a lot ... ... Nobody wants to hear that **GitHUB Flow** is just one of three major forms of TBD: trunkbaseddevelopment.com/styles/.

I got the feedback the tone of the post is a bit hard, accusing, even condescending. Is it? #genuinequestion

Additionally, a branch is a little kingdom the dev feels is theirs to control. I think many also fear losing that turf.

Yes, and then the kicker is in the conclusion… ‘Adopting trunk-based development is not the first step. It is step 20 on a journey most teams have not even embarked on.’

Published: Why do Teams think Single-branch Development Does not Work? Despite research showing that Continuous Integration indirectly leads to better quality and stability, implying the practice of trunk-based development, teams believe this cannot work for them. thinkinglabs.io/articles/202...

Published: Why do Teams not practice Continuous Integration? Everyone in the IT industry agrees that Continuous Integration is a required practice to realise quality and stability. Yet, few teams have truly implemented Continuous Integration. Why is that? thinkinglabs.io/articles/202...