Agile

Peter Schmidt talks with Graham Lee about whether spec-driven development is a genuine successor to agile or just waterfall wearing an AI costume. A good counterweight to the “agile is dead” hype cycle, with an extensive set of links to the broader debate in the show notes.

Lorin Hochstein stages a short play in which an engineering manager discovers the “carefulness knob” — the dial a team implicitly turns when deciding how much testing and process rigor a change deserves. The punchline is that cranking it to maximum doesn’t eliminate incidents, it just pushes delivery dates out exponentially, and teams are far worse at estimating risk than anyone would like to admit.

Barry Jones makes a thorough case that story points are unreliable by design: low values imply precision, high values imply ranges, and velocity quietly converts them back into time anyway. Instead of arguing about Fibonacci numbers, he argues teams should measure queues — how long work waits — which gives the business the timeline predictability it actually wanted.

The Choluteca Bridge in Honduras survived Hurricane Mitch intact — but the hurricane moved the river out from under it. Mike Bowler uses this as a memorable parable for long delivery cycles: you can build exactly the right thing perfectly and still miss, because the world changed while you were building. The antidote is shortening the time from idea to in-use: smaller slices, less work in progress, fewer dependencies, and real collaboration.

Linear is repositioning itself as “the product development system for teams and agents” — issue tracking, planning, and triage built around workflows shared by humans and AI agents. Worth a look if you’re thinking about how coding agents fit into an existing project management practice (and, as always, the design and performance polish of the product itself is exemplary).

Industrial Logic frames code quality as a set of seven “virtues” — qualities like clarity, simplicity, and testability — rather than a checklist of rules. It’s a useful vocabulary for code review conversations, giving teams shared language for why a change feels better or worse beyond “I don’t like it.”

via Martin Fowler (@mfowler@toot.thoughtworks.com): @emilybache@sw-development-is.social has set up a github repository with code samples in several languages for the opening chapter of my Refactoring book. She’s posted a video to her YouTube channel where she introduces this Theatrical Players kata.

Martin Fowler works through the Theatrical Players kata from his Refactoring book, narrating each small, behavior-preserving step as he goes. Watching someone with this much experience talk through the reasoning behind each move — and lean on tests at every step — is far more instructive than reading the finished code.

via Bruno Baketarić: “There’s a commonly held myth that a lack of a time-bound delivery commitment, such as a sprint demonstration, will lead to a lack of focus, laziness, and increasingly long delivery times. There is, in fact, no such evidence from more than a decade of training and coaching for a living and wish to dissuade adoption of Kanban or customers from switching.” (David J. Anderson, 2023 in ‘Discovering Kanban’, p. 108)

via Kevin Stewart: There’s more to life than OKRs: using EOS and W Planning for effective goal-setting in empowered teams

via Kevin Stewart: If agile isn’t dead, why is it still not working?

via Mike Bowler: We’ve announced another public class of Applying Metrics for Predictability over the weekend of October 14/15.

via Matt Weagle: “By the end, you’ll be prepared to operate effectively within an existing planning process, balance functional and cross-functional demands, and diagnose how your current planning process may be holding Engineering and your company back.”

via Jon Reid: I teach using mob programming. But the pandemic forced us all to be remote. Here’s what I tried, how it worked, and what I changed going forward.

via Martin Fowler: I’ve written a brief summary of Team Topologies, the model created by @matthewskelton and Manuel Pais at @TeamTopologies. Many of my colleagues are finding this to be a useful tool to think about how best or organize software development teams.

via Alper Çuğun-Gscheidel: Every time I mention slack time as one of the most important things for healthy engineering teams people look at me as if they’re seeing water burning.

via Mark Levison: Backlog Refinement can prevent Zombie Scrum — I love the phrase Zombie Scrum. It conjures to mind teams using the practices of Scrum and getting limited benefit. They ran a workshop with their subscribers to find what was helping them with #ProductBacklogRefinement.

via Mike Bowler: I’ve noticed anecdotally that for a development team, as WIP goes down, quality goes up. I’m thinking my way through how I would visualize that and any suggestions are welcome. I can easily pull WIP numbers out of Jira (all my clients use Jira — sigh). The trick is how to measure quality. Pulling number of bugs entered into Jira can be done but absence of bugs doesn’t prove quality. SonarQube has some technical quality data but quality is more than just code.

via Mark Levison: Mise en place of Great Scrum Teams, Christiaan Verwijs — outlines 5 strategies on making refinement better:

via Mark Levison: Kent McDonald offers a Kanban Board to visualize your current understanding of the state of the product backlog.

Hot take (that may lead to some “interesting” conversations when I get back from sabbatical): Points or other detailed project estimates in software project management are a waste of time.

via Mark Levison: Solid summary article that covers INVEST (Yay), DEEP (good), Definition of Ready (maybe).

via Mark Levison: Silent backlog refinement meetings: a more effective Agile meeting.

Gareth Davies at Parabol: What is Backlog Refinement?

via jadeforrest: 🧠 FAST agile is the most interesting organizational practice I’ve learned about in a while. Today I share what FAST agile is, and explore whether it’s worth experimenting with.