Agile Otter Blog

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

Aint No Plannin' I see a lot of "agile" teams and their "planning" meetings, but if you forgive me for saying so, I've not seen a planning meeting for a long time.  Typically: No plan is presented No questions about the plan are surfaced No revisions to a plan are made What actually happens then? Usually, someone loads up a list of tasks, and the entire meeting is spent assigning people to the tasks. Does that in ANY way resemble planning? What was planned, other than individual workloads? How was the plan assessed, improved, revised, or confirmed? What was, even, the plan?  So, what I have in mind is simple. Don't Assign In your next planning meeting do not assign any work to any individuals.  They can pull work as part of the sprint. They are cross-functional and self-managing, right? They are professionals you trust and respect, and have autonomy, so they can pull work.  If you are the PO/PM, then you have an ordered backlog for them. Show Your Plan P...

Some time ago, on a social media platform, during a discussion about technology, a pundit posted a piece arguing that teamwork was a horrible idea.   The Compromise Theory: His thesis is that an individual can have a great idea. When other people get involved, they have differing ideas. To settle the differences, the group has to make compromises.  Every compromise is a degradation of the original idea's purity. By definition, he said, every compromise is a second-best choice.  Eventually, the idea is so diluted and compromised that it is hardly worth implementing. The Contribution Theory: Cross-functional, diverse teams are well-documented and understood. They make better decisions, make rapid progress, and approach a problem from more angles.  The thesis here is that "two heads are better than one" for problem-solving, and that the work of an individual (rather than being perfect and pure) is likely to have more flaws and a narrower vision than the work of sev...