“Finishing Your To-Do List Means You Aimed Too Low” [Silicon Opera].
Every sprint, they completed every ticket. Not most tickets. All of them. The board cleared cleanly at the end of every two-week cycle, like a program that always returns zero.
Somewhere around the eight-month mark, a new engineering director joined the company. Within her first two weeks, she asked a question nobody had thought to ask: what work didn’t make it onto the board?
And:
The answer was uncomfortable. Quite a lot of work hadn’t made it onto the board. A significant backlog of architectural improvements had been mentally shelved because they were “too big to sprint on.” A recurring data pipeline bug was handled informally, never ticketed, because it was faster to just fix it than to log it.
The sprint board wasn’t capturing reality. It was capturing a curated version of reality, sized specifically to fit within two weeks and feel completable. The team wasn’t finishing their work. They were finishing the work they’d pre-selected for finishability.
(Goodhart’s Law. The solution is in the full piece.)
GTD (Getting Things Done), the productivity framework David Allen popularized, actually addresses this directly. The system’s core premise is a ‘trusted capture’ mechanism, somewhere outside your head where you put everything, not just the things you plan to do soon. The assumption is that your mind will not give you peace about an obligation until you’ve captured it somewhere you trust. But most implementations of GTD, and most task management tools, optimize for execution over capture. They reward you for clearing items, not for capturing them honestly.
I’ve always hated do-lists, and this piece explains why. “Empty the trash” and “boil the ocean” can both be on it, which seems silly. Checking off “empty the trash” — and maintaining the list item — feels like work, because it is. “Boiling the ocean” is important, but I have to sit down and think about it. Meanwhile, in the real world, plenty of problems just go away if you just wait and let them.
The only time I’ve made a do-list was site-building, where there are two damn many things to keep in my head. Proving, as the author says, that software is different: “The backlog of potential improvements is effectively infinite.”
Comments
Yep, go get the trash ready for tomorrow. Then Friday go into town get tags for my little truck with fingers crossed I don’t get caught without of date tags. Then get fuel before I run out, I hope I make it the station. Then if that all works as planed Tacos.
Then stay on new diet.
… with cataloguing and then breaking down one’s tasks into chunks, then figuring out what order to perform them depending upon effort, timeframes required, and priority.
But yes, software is definitely different (“A woman’s software engineer’s work is never done” 😁).
Back in the depths of time when I was a QA engineer, newbies were always told about the impossibility of finding and fixing every bug. The example given was a program that could take one- or two-digit integers and add them together to produce and display the result. Such a program has more than 40,000 possible paths through it.
Most programs are of course orders of magnitude more complex. So testing would never be able to find all issues — at least if you want to ship it before it becomes obsolete!
This time around, it’s the strike through font tag that didn’t work (on the “women’s” in the parentheses above).
Maybe it’s my browser? DuckDuckGo browser on iPad.
I made sure that I didn’t accidentally delete the closure tag this time.
To Do