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 ...

It worries me that we're losing the war against rightwing disinfo. There is no rational reason the shooting of Charlie Kirk made global news while Melissa Hortman's murder barely made national news & everybody has forgotten they blamed this on the left as well www.theguardian.com/us-news/2025...

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...

Published an update to: On the Benefits of Trunk-based development Added the missing: - enables incremental software engineering skills - encourages refactoring - this has worked for regulated industries and large IT systems thinkinglabs.io/articles/202...

We don't do politics here. Yeah right. You are lying to yourself (and believe it). Business is politics!

Published: On the benefits of trunk-based development Whenever we suggest trunk-based development, we are called unprofessional and belittled. How can we possibly produce quality? But in all honesty, for trunk-based development teams, quality is the highest concern. thinkinglabs.io/articles/202...

No comment 🤷 #socrates2025

There is no such thing as a target architecture thingy. We can only try something and coarse correct. We should eradicate this "target architecture" thinking from our vocabulary. Really! It is not helpful, and it creates the wrong expectations.

Doing otherwise somehow remembers me the waste. effort and delays I find in big pull-requests reviews and long lived branches merge as opposed to TBD /cc @tdpauw.bsky.social

Published: The Struggle of Public Speaking Sometime in 2022, the lovely people of FourScouts invited me to share my experiences with public speaking, including the challenges and rewards. thinkinglabs.io/articles/202...

I seem to have a difficult relationship with the French conferences except for @flowcon.bsky.social 🤷

When a team of six tells is they practice scaled trunk-based development, chances are what they are really doing is GitHub Flow with too many branches living for too long. Probably they are nowhere close to trunk-based development.

Genuine question, does the fingerprint auth on Windows actually work, like it always unlocks on first try? 🤷

Published an update: On the Evilness of Feature Branching - But Compliance? A recent conversation on LinkedIn nudged me to add more lean alternatives to using Pull Requests to satisfy compliance. thinkinglabs.io/articles/202...