Agile Otter Blog

Some time ago, Jeff Langr and I came up with seven virtues for code in Agile in a Flash , and we wrote more about them over the years.  The original set is:  Working, Unique, Simple, Clear, Easy, Developed, and Brief. The virtues give us some words for what we like about good code, and they've been remarkably stable, with two exceptions: 1. I've added the 8th Virtue ("Coherent") 2. I've dropped the ordering. Working is non-negotiable; the rest work in balance. Since I've added an 8th and people have expressed interest, it seems prudent to produce a new, fully unified version of the list with more examples and suggestions to help people translate the rules into skills. This write-up is for human consumption, of course, but there are notes and recommended readings that may help in other purposes. Let's begin: --- Evidence, Subjectivity, and Judgment The virtues are not all subjective qualities. Clear is subjective because clarity exists in the relationship...

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