Agile Otter Blog

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

 I've written repeatedly about the 7 Code Virtues, and they have been reliable guides for me, as well as a language for describing goodness in code. When I started applying this agentically, I realised that I may have been wrong about ordering (as I suspected all along) and adjusted to 'Working is prime, the rest are equal', and this has served me well. The agentic code still wasn't going as well as I hoped. After a bunch of reflection, ChatGPT, and trial and error, I discovered that I was missing Coherence.  Most simply described, coherence is the degree to which concepts, abstractions, vocabulary, architecture, patterns, and representations of the system reinforce one another. Over its evolution, a coherent system increasingly feels like a single language. This goes hand in hand with the 'developed' code virtue. Coherent systems increase the value of learning because knowledge gained in one part of the system becomes useful elsewhere. This raises the bar for ...