Tools like Jira are bureaucracy-management tools, not Agile tools. You don't need a backlog at all to get work done—a handful of index cards or stickies work just fine, and more than a couple of weeks' work in that pile is too much. 1/3

Does an AI write better code than a human programmer? Not in my experience. Does it, with sufficient guidance and guardrails, create good-enough code faster than a human? Absolutely. The question is all about cost and quality, not, as some would contend, about the code itself. 1/2

There are three sorts of Scrum: 1) Scrum as defined in the Scrum Guide—the official definition, but hardly anybody's read it & it's horrifically badly written. 1/3

If you didn't measure productivity before you started using AI, a current claim that AI improved your productivity has no legitimacy whatsoever. And even then, how did you measure productivity? That's very hard to do.

OH: "That works fine with a startup, but it won't scale." Most people assume that as an organization grows, you must replace effective ways of working with a bureaucratic command-and-control, phase-gated (waterfall) system. You don't. 1/3

Many people have heard about the Dunning-Kruger effect: people don't know what they don't know, so they inaccurately assess their own competence. Everybody puts themselves in the 99th percentile of good drivers, great programmers, or AI users, even though that's statistically impossible. 1/10

The notion of an MVP has gone the way of Agile. 1/11

🌟 𝗠𝗲𝗲𝘁 𝘁𝗵𝗲 𝗦𝗔𝗚 𝟮𝟬𝟮𝟲 𝗞𝗲𝘆𝗻𝗼𝘁𝗲 𝗦𝗽𝗲𝗮𝗸𝗲𝗿𝘀! 🌟 We’re incredibly excited to welcome 6 outstanding speakers to #SAG2026 in Berlin: 📅 𝗡𝗼𝘃𝗲𝗺𝗯𝗲𝗿 𝟭𝟳: @bjschrijver.dev, @allenholub.bsky.social & Sam Newman 📅 𝗡𝗼𝘃𝗲𝗺𝗯𝗲𝗿 𝟭𝟴: Aino Vonge Corry, Radia Perlman & @randyshoup.bsky.social 👉️ t1p.de/3xyd5

I just had a conversation with a wide-eyed idealist programmer who was working alone (using an AI, but that's still alone) creating an app. 1/4

Today's Pragmatic Engineer newsletter [https://t.ly/ltiYl] was talking about Meta's misguided attempt to fire everybody and replace them with AI. Zuch was evididently thinking (if you can call it that) that mass layoffs would make them look more like a startup. 1/9

<rant> I came across yet another person today blathering about "collaborating with an AI." I'm sorry, but collaboration requires real intelligence, creativity, judgment, reliability, emotional intelligence, and a host of other qualities that no AI has. You collaborate with an equal. 1/2

If you are "writing a user story," you're already in trouble. A "user story" is exactly that, the user's story. They're the ones who "write" the story, not you. A user story is not a code word for a waterfall up-front specification. A "story" describes your user's work, not yours. 1/4

When a customer or user asks for a specific new feature or change, the first question to ask is "why do you need that?" or, better yet, "what work are you doing, and how would that feature make your life easier?" 1/2

If the first time you get feedback is in your "Sprint Review" or "Demo," your Sprint has probably failed. Your goal is to deliver the most valuable thing. If the review feedback tells you that you need to make a change, then you have not delivered the most valuable thing. 1/3

I keep hearing people whine about customers changing their minds. That's our customer's job! Nobody knows what they want until they have something in their hands (including us). 1/4

Join our #YOW26 Masterclass with @allenholub.bsky.social: Domain-Focused Component Architecture for AI-Assisted Development 📍 MEL 2 Dec yowcon.com/melbourne-20... 📍 BNE 9 Dec yowcon.com/brisbane-202...

I get sick to death of hearing people say that customers don't know what they need. That's nonsense. They know exactly what they need. They need solutions to their problems, and they need tools that make their lives better. It's _our_ job to collaborate on the details of how to do that.

The only measure of productivity that has any meaning at all is the ratio of money spent on the work to revenue created by that work. I couldn't care less if AI made you "10x faster." If that work didn't increase revenue, your productivity hasn't increased. It may have gone down, in fact.

Productivity is a systemic measure, not something you can isolate to a team or department. If "more productivity" in engineering creates a release that makes tech-support expenses go up, you are not more productive. Sorry.

One hallmark of a lousy app is that it's chock full of features. A good app does one critical and necessary thing well. A pile of features typically does nothing but add clutter and make the app harder to use. 1/12

It seems like every time I look for something on the App Store, I find a huge pile of apps, none of which are any good. They are bad because they were not built with customer collaboration and feedback. They don't actually solve anybody's problem. 1/4

Back in the 1980's, when dinosaurs roamed the Earth, people defined programs as data flowing between multiple processing units or functions, each manipulating or otherwise using the data as it passed through. Languages like COBOL supported and amplified this thinking. 1/14

When it comes to APIs, most people get things backward. The best way to create an API or any other interface is to start with the code that uses the interface. 1/4

"Scientists" believe life began in underwater hydrothermal vents 4 billion years ago. I believe it began at the Denny's off the interstate in Toledo Ohio in 1956. I don't make fun of their theory and yet they constantly ridicule mine. And that's what's wrong with our so-called elites

I really don't like the notion of "ownership" when it comes to the code (or the associated notion of accountability). This is all about finding a single neck to wring. It's a form of blame, bullying, and control. It's a disease. Instead of ownership, go with collaboration. 1/4

It's never a good idea, in my experience, to split an application horizontally—into back-end and front-end subsystems assigned to different teams, for example, or into separate application and platform teams. 1/10

This

ART, the Agile Release Train, in real life 👇

Code is, in and of itself, not valuable. In fact, if the code is not making the product better in the eyes of your cusomtomers/users, then it's a liability—money spent without a concomitant return. Consequently, any measure of code volume is worthless unless it can be correlated with value.

I've found that using TDD as part of my process, when I specify the tests and then tell the AI to get them to pass, works pretty well. However, I was just reading an interesting post from Birgitta Böckeler at Thoughtworks about using TDD inside (!) the agent loop [https://t.ly/U0KfM]. 1/11

TDD inside the agent loop - theater or actual value?

Notes from my Thoughtworks colleagues on AI-assisted software delivery

t.ly