Agile Otter Blog

 I don't know if there is another name for this pattern, but I've been calling it "progressive admission" and using it for many years. It is a story splitting skill, related to the "walking skelton" AKA "tracer bullet" technique. Say you are about to build a program that reads from a message queue and processes messages.  Start Closed The first stage is to build the end-to-end system (reader, checker) that does nothing. No matter what you feed it, the front-end checker (correctly) reports that it's not implemented. This is beginning all closed.  At this stage, you can start testing the clients and the exception handling/reporting.  First Admissions Now you pick the simplest message. It could be a health message or an ill-formed message. This one message or message type is admitted . The program correctly rejects the ill-formed message, or answers the health message with a hard-coded message result. At this time, all other messages are rejected ...

This is a blog I wrote on ButUncleBob (the Object Mentor blog) in 2006, republished here verbatim because that blog is not always available and because it still matters.

 WARNING: this is an AI generated article -- but that's on purpose. Without any priming or preparation, I asked a chatbot about sprints and tickets, and got this as an answer.

 I published my first post on Sooner, not Faster  in 2006 on Object Mentor's blog ("But Uncle Bob!" was the title), a wiki I was encouraged by Bob to use daily. Later this theme had been picked up by many people. Ryan expanded it to "Sooner, Safer, Smarter" and I appreciate that also.  I've had years, decades in fact, to be working through what it means to deliver sooner and more often.   I've been introduced to many concepts that are related, and I've created a short guide to flow to help people quickly come to terms with the systems view (ToC, Reinertsen's Flow, Continuous Delivery) as a mechanical system of queues and inventories.   That is a very important lens that brings us to appreciate that we can do better without working harder, longer, faster, or even agentic aids. It even explains why working harder, faster, longer, and with code agents hasn't really panned out so far.  What really does matter is story splitting, writing good code...

  Companies often build their software development as a series of handoffs . Every handoff is a queue . Queues determine how long work waits . The busier the person receiving queued work is, the deeper the queue becomes , and the longer work waits to be served.  A common mistake is to obsess over developer  cycle time (ticket closure) and ignore the rest of the process. For flow reasons, it is better for people to be waiting on work than for work to wait on people. Rejection loops  send work products back to earlier stages, disrupting waiting work and delaying release. Rejection loops in the process make prediction for all work products difficult, if not impossible. Collaboration, quality practices, small batches, trunk-based development, and early feedback all work because they improve First-Time-Through and reduce rejection loops. Ignoring those kinds of measures means you have no flow protection. Once rejection loops become rare, the remaining delays are lar...

The Faros report on AI-assisted development has been rattling around in my head for a few days. The story it tells is a strange one: Teams are producing more code.  More tasks are being completed.  More pull requests are being created.  And yet : waiting times are up,  review times are up,  lead times are up,  incidents are up, and  bugs are up.  The picture shows a development process that's getting busier without getting faster. My first reaction was the same as everyone else's. Maybe the AI-generated code just isn't very good. The report certainly contains evidence that quality is suffering. But the more I looked at the numbers, the more I focused on waiting times. I've spent enough years looking at value stream maps to have a habit of looking for queues. A surprising amount of "developer behaviour" turns out to be queue behaviour in disguise. A review problem turns out to be a queue. An approval problem turns out to be a queue. A testing probl...