Agile Otter Blog

When I said tickets have almost nothing to do with agile software development, I was greeted with some very odd looks and incredulous "huh?"

I remember the 80s.

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.

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.

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.

I published my first post on Sooner, not Faster in 2006 on Object Mentor's blog ("But Uncle Bob!"

Companies often build their software development as a series of handoffs.

The Faros report on AI-assisted development has been rattling around in my head for a few days.

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.

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.

If you're curious how your pipeline and its pass rates affect your team's regular work, check out the Pipeline Gates Calculator.

I believe in people.

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.

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 riskiness of a release is proportionate to the number of potentially untested paths in the new code.

People are making a big deal about the new way of agentic working: Spec-Driven!!!

This is one of those things that just doesn't stick in my head, so I'm dropping this note to remind myself.

A bit of background: I was chatting with some colleagues and friends this week about AI-augmented workflows.

You're working with some Python code, and would like to write a test, but...

Sometime back in my early days of programming, I learned to enjoy a truth table.

Here is a .vimrc file built from the recommendations in my Vim book, "Use Vim Like A Pro" (available on LeanPub). " =================================================================== " Basic .vimrc Configuration " Based on recommendations from "Use Vim L…

Recommended bash scripts for every project clean_start ensures you are ready to start new work.

Working faster isn't working?

This is probably too snarky, but bear with me: If I fill my fuel tank with non-fuel or the wrong fuel, it will damage my car and fail to perform.

i will submit that the problem of scale is mostly that you Have to deal with divergent, incompatible SW development paths Might not be able to handle losing fine-grained control of every element of the business.