标签：#Agile

I'm a scrum master. I was a developer ten years ago. I have enough background to discuss design and trade-offs with an LLM — but three months ago I made a deliberate bet on my solo project: I would never read the code. The specs define the tests. The tests control the code. The code is a black box. I'm not claiming this is what everyone should do. But it's my bet, and it forced a system into existence: when nobody reads the code, the process has to carry the trust that a code-reading human normally provides. I've just published that system as a reference implementation: backlog-as-data — the full writeup, the Claude Code skills translated to English, and the CLI source, verbatim from my daily setup. Here's the short version. The backlog is git data, not a document Most agent task-management tools store tasks in a dedicated place — a tasks.json , a database, a backlog/ folder. My bet is different: the backlog is the YAML frontmatter of my spec files. One file per ticket, and the ticket's status is a field — never a location in a document. --- id : PARSE-07 title : Tolerate CRLF in decklist import type : ticket status : todo priority : should exec : model : sonnet effort : think review : light matured : 2026-07-22 --- # PARSE-07 — Tolerate CRLF in decklist import The spec body: design, contracts, test cases. The ticket file IS the spec. Everything below the frontmatter is the spec — written by the LLM, after it has challenged the need I expressed in conversation. The frontmatter is data — owned by a small CLI, mutated only through it. Same file, so they can never drift apart. Why it matters: "move it to Done" is not an operation. LLMs (and humans) mangle documents when a state change means relocating text. Making status a field makes every transition a one-line, idempotent, testable mutation. The board I look at (a small web page on my server, with GitHub deep links to each spec) and the readable markdown view are generated projections , locked by a do-not-edit sentin

Every team I've worked with has a version of the same Slack message. Someone posts a PR link, adds a...

AI Doesn’t Replace Agile. It Makes Good Agile More Important. The discussion around AI replacing Agile is becoming increasingly common. The argument usually goes something like this: Information is now instantly accessible. Code can be generated in hours instead of weeks. Documentation is no longer expensive to produce. Communication overhead is dramatically reduced. If all of that is true, do we still need Agile? I believe the answer is yes—but perhaps not in the way we practice it today. The mistake is assuming Agile is defined by stand-ups, sprint planning, retrospectives, or two-week iterations. Those are practices, not principles. The real purpose of Agile has always been much simpler: Deliver customer value incrementally while maintaining enough structure to ensure quality, accountability, and continuous learning. That objective hasn’t disappeared because AI became faster. AI Changes Execution, Not Responsibility Large language models can generate code, documentation, tests, infrastructure, and even architecture proposals. What they don’t generate is accountability. In enterprise environments—especially regulated industries—the question is rarely “Who wrote this code?” The real questions are: Who owns this decision? Why was this solution selected? Can we trace how we arrived here? Can we audit the process? Who is responsible when something fails? Without clear ownership and controlled handoffs, AI can produce enormous amounts of output that become increasingly difficult to understand, validate, or maintain. Speed without governance simply creates technical debt faster. Coordination Isn’t Going Away Many people assume AI eliminates the need for coordination. I would argue the opposite. As AI agents begin collaborating with humans—and eventually with other AI agents—the need for explicit coordination actually increases. Someone still needs to define: objectives, responsibilities, interfaces, quality gates, acceptance criteria, governance, and success metrics. Th

I said "maybe a couple days" on a call last Tuesday. By Wednesday morning it was in a Jira ticket as "2 days." By Thursday afternoon somebody was checking in to see if we were tracking against the two day commitment. Nobody did anything wrong. The person who wrote it down was capturing what I said. The person checking in was doing their job. I was the one who said the words. The system worked exactly as designed. The system is the problem. Something Ive learned is that theres no such thing as a rough number in meetings today with all of the AI note takers... The moment you say a number out loud, it stops being a feeling and starts being a quote. The hedge in front of it doesnt survive the transcription. "Maybe" disappears. "Couple" gets rounded to a specific integer. "Give or take" is the first thing that hits the cutting room floor. What lands in the document is the number, naked, with no caveats and no error bars. Everyone in the meeting heard what you heard. They heard the hedge. They watched you wave your hands. They understood, in the moment, that you werent committing. But the document doesnt remember any of that. The document just remembers the number. And the document outlives the conversation, which is where all the nuance lived. Ive watched myself do this for years and I still get caught by it. Someone asks how long something will take. I want to be helpful. I want to seem confident. I want to keep the meeting moving. So I say a number. The number is approximately right, or at least I think it is, but I havent actually thought about it the way you would think about it if you were going to commit to it. By saying it out loud, Ive committed to it. The fix, if theres one, is to refuse the number. Not rudely. Just clearly. "I need to look at it before I give you a real number. I can have one for you by Friday." This works about half the time. The other half, somebody in the room is going to ask you for a ballpark anyway, and youre going to give them one, and t

InfoQ celebrates its 20th anniversary. To mark the occasion, we have published a walk-through of the trends InfoQ called early, where they sit on the adoption curve today, and how that curve may evolve over the next decade. By InfoQ

Today, June 8th, InfoQ celebrates 20 years. This is not a comprehensive history, but a deliberately selective look at the technologies and practices InfoQ identified early, where they sit on the adoption curve in 2026, and how that curve may evolve over the next five to ten years. By InfoQ