“For example a team might be writing an implementation of a system where the behaviour is well understood.” Isn’t this very rare, and given the difficulties with many software projects? The norm in my experience is that some behavior is discovered during the act of designing and developing the software, hence the need for collaborative teams (like Scrum teams.)

I would say that in general this is rare, but was taken from a real example of something that I am working right now. There is still uncertainty since we have a functional spec as opposed to a design but the value of fortnightly feedback from a product owner, say, is diminished.

In many ways, agile is common sense. Unfortunately, common sense is sometimes uncommon. My take is that Scrum defines a simple set of protocols for teams to manage and monitor work. By understanding and using Scrum, you avoid re-inventing the wheel. And many other things are still up to the team, like determining which technical practices will be used. The Scrumbut problem comes into play when people discard the very things that can maximize their benefit and productivity – without understanding what they are discarding.

“For example a team might be writing an implementation of a system where the behaviour is well understood.” Isn’t this very rare, and given the difficulties with many software projects? The norm in my experience is that some behavior is discovered during the act of designing and developing the software, hence the need for collaborative teams (like Scrum teams.)

I do share your concern that you don’t want to get too process-focused. In situations where “process is the thing,” many other important aspects of software development get overlooked.