I’ve been talking about software process for a long, long time. Something I notice is there are people who are uncomfortable taking responsibility. They want a process where they can say, “Well, hey, we executed the process. We failed, but we executed the process.”

Beck expands on this in another interview. The old saying “you can’t get fired for choosing IBM” lives on in modern software engineering practices. I see this a lot at BigTech and I interpret the problem through the lens of ownership. Teams own software, and should own the process they use to develop it.

Teams own software, not change or process.

It’s easy for a team to follow SCRUM - there’s a lot written about it, and you can be a Certified SCRUM Master in just a couple of days for just a couple of thousand dollars. Dysfunctions in the team’s delivery practices or development velocity can’t be due to due to approach, because they’re using a prescribed methodology like SCRUM. Contrast this to a team which evolves its own way of working which veers away from such a prescribed model. If the team is hitting delivery speed bumps then to an outsider the first thing to fix is this non-standard process, not any underlying context.

Another example are working groups created to drive an initiative. As long as the group is made up of relevant stakeholders, they meet at a prescribed cadence, and they decide something, then any failure can be explained away. Ineffective working groups tend to achieve nothing, that is, they make no positive impact on the organisation.

It’s easy to follow the prescribed process, one can’t get blamed for doing so. The result is a lowest common denominator form of practices. This isn’t bad in itself, but it does not inspire, does not challenge, and is not the most effective way of working.

For my own initiatives at work I apply the lens of Extreme Ownership. This involves being selective in what I commit to - is it a change I can even make, or would I justify my failures by using “I followed process and did the best I could” as an excuse? For the things I commit to I set clear success criteria for what I want to achieve, when I need to do them by, and dependencies and allies who will help me get there.