The best book I know about both software design and system improvement is a book about physical architecture called How Buildings Learn, which is broadly about how people adapt buildings over time. One of the main themes of that book is that people love simple, cheap buildings, because simple, cheap buildings are easy to change. A building that's easy to change is a building that's easy to adapt to your current needs. People's needs change over time, so to be happy living in a building for a long time, they need to be able to change it with them. Even the most perfectly designed building will eventually come to be loathed by its inhabitants, if they can't change it.
So it is with software, and with the socio-technical systems that create software. A system that's not working is probably a system that's not changing. If a system isn't working, the most useful thing I can do is get it changing. (If you're part of the Jerry Weinberg tradition you will recognize this as the philosophy behind "jiggling" and the "whatever your client is doing, recommend they do something else" advice.)
The great thing about this is that it means I can solve a wide variety of problems with straightforward, general purpose techniques. For technical problems this means investing in testing, deploy speed and observability. The major barriers to change for technical systems are usually poor understanding of the impact of changes, and attempts to manage the resulting safety problems with time-consuming quality processes. So investing in making systems changeable tends to improve their design over time – something I wrote about in more detail a few months ago.
For the human side of systems problems – the engineers are bored, don't trust each other, don't believe what they're working on is important, are wasting a lot of their time on rework and failure demand, or aren't working well together for whatever reason – this means practicing making changes and evaluating their results until the team is good at it, typically by introducing and improving retrospective meetings.
Improving retros is tricky, though, because a good retro requires a mix of both skill and belief. To make changes you have to believe that change is possible, that you're allowed to, and that it's worth the effort. At least in America, our school system and managerial culture both really push in the opposite direction, so by the time I've got folks on a team with me they've got a lot of experiences telling them that it's not worth the effort to try to improve their process workspace.
One thing that people often need to establish an effective retrospective culture is to just practice changing stuff, and build up a bunch of experiences where they made a change, talked about what happened, and then made more changes based on the information they got.
I often find myself encouraging the team to tinker with standup. Stand-ups often kind of suck. They definitely can be useful but they often slip into being a rote status update, drag on long past their welcome, or end up lodged at some awkward time of the day. There's always something that can be improved about standup, and someone who's dissatisfied with it in some way. Since standup is such a short meeting, changing when it's held, how it's facilitated, or what's on the agenda often feels like a relatively low-stakes change, so it's easy to get people to agree to try things for "just a week." But since it often happens every day, even in a week you can accumulate a lot of experience with a new variation on it, and have plenty to talk about in next week's retro.
I think this surprises people. When and how standup is held is sometimes mandated as part of "Agile transformations," which seems bonkers to me – at best, much more about the power and comfort of senior leaders than about the ability of their organization to make software. Folks outside the team will hear that we've moved standup three times in the last week, or we're not doing it at all, or it takes an hour, and the response is something like, "Wait, what? You can do that?"
Which is one of the things I like about that kind of consulting. Yes. You can do that. You can change the systems around you to make yourself more productive, and more comfortable.
A simple assignment
So here's what I want you to do.
Do you have a retro? Does your standup kind of suck, but you tolerate it because. hey, standup, amirite?
I want you to show up in retro and put "standup" on the board. And I want you to ask your team to come up with something small you can change about it. Make it shorter, make it longer, give it a formal facilitator.
And then I want you to write back to me and tell me how it went. Reply to this e-mail or put "standup" in the e-mail. (I'm nat @ this website.)