Agile Otter Blog

  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.  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 largely visible and manageable. Ignore these basic facts, and delivery cannot be efficient, quick, or predictable.

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

 There is a commonly shown drawing, which came from a great Kniberg post (of course), explaining how every iteration in an agile development method produces something usable, and the capability of it grows over time. Rather than building parts to assemble later, as typically is done in function decomposition and bottom-up building. I reproduced the image here, to introduce the topic better. Of course, critics answer by saying "well, if I ordered a car, I don't want a scooter or a motorcycle! I want a CAR!!!"  This argument misses the point entirely, but is frequently given as a counterargument. Henrik's point was that in the crossed-out picture, you have to wait until the whole car is constructed before you get any benefit at all.  The point is not that we "wasted time" building intermediate forms, but rather that we began producing value from the start and increased it over time. Henrik Kniberg is entirely right, yet people keep insisting that you have to d...

If you're curious how your pipeline and its pass rates affect your team's regular work, check out the Pipeline Gates Calculator . It's just a toy, but it may be enlightening. For each of your quality gates, enter the name of the gate, about how many minutes it takes to operate that quality gate (maybe automated tests run in 5 minutes, or manual test in 60*16 minutes), and the pass rate. Name -- field is just for you, to remind yourself what the gate is Time -- how long it takes to do the check, in minutes Pass Rate -- how often items go through the gate on the first try (100% for advisory-only gates) Include code reviews, automated tests, security scans, human approvals, whatever. When you have entered them, run the simulator.  It doesn't do a lot of simulating, It does 10 runs of 100 work items, instead of running tens of thousands. It will report averages, though.  The rule is that if any gate fails, the work item has to be resubmitted and pass through the gates again...

 I believe in people.  People are amazingly strange creatures. They walk this ridge between depression and anxiety, and walk it with joy. The world need to be stable enough that they can grow competence and skill. When it's too stable then they become bored and depressed, because it's all easily within their skillset and there is no growth or learning; they've been there and done that. When things are not stable enough that they can develop competence, that's chaos and anxiety. The stress of constant change burns them out; they will often just quit trying and then submit to boredom again. In many people, chronic anxiety seems to me (a layman without special training) to be defined as being afraid that they might become afraid. It's weird how we can be like that - fearing fear so much. Of course, we tend to fear most overly-strong emotions, and I have to wonder how much other animals fear themselves. When they do what they're good at, people are beautiful. Watch ...