I appreciate that this question may be controversial. In a sense, it is the flip-side of the question "Business trying to make technical decisions".
In Scrum, the development team is supposed to be collectively responsible for making design and technical and code-level decisions, to fulfill the customer requirements. There is a division of responsibility and power between the product owner, who defines and prioritises the stories by communicating with stakeholders, and the team, who decide how to implement the stories.
I think this is motivated by the belief that, since developers are intimately familiar with the code they have written so far, and all the information they have memorised or noted about the project, and they will face the consequences of poor decisions when they have to modify the code in future, they are best placed to make design decisions. And if in hindsight they realise they made a bad decision, it will be a very valuable learning experience for them, and they won't be able to blame management for what went wrong. In theory, I agree with all this. But (to kind of play devil's advocate) I can see several situations in which following this principle to the letter could be a bad idea:
- The development team are mostly either temporary contractors, are (unbenownst to others) intending to jump ship, or are going to be made redundant after shipping this project, or are going to move to another project and there is an entirely separate team which will do "code maintenance". (A good example of this might be: a typical outsourced government computerisation project.) So, for any of these reasons, the team mostly aren't the people who will be doing the actual maintenance.
- Or, the development team are all inexperienced developers who don't really have a clear idea of the maintainability problems that can be caused by slipshod development practices or poor design decisions. While they have an incentive in theory to do the right things, the incentive isn't working yet because they haven't been burned enough times (or they haven't acknowledged the connection between sloppy coding practices and getting burned).
- The development team like making big mistakes and working crazy hours to fix or work around them because (a) they are workaholics, (b) they like wasting time writing boilerplate code or using some bad old framework because it gives them a sense of job security, or (c) it makes them look like or feel like heroes.
- The team like to endlessly bikeshed, or discuss endless different permutations of ideas, or add "internally-visible features" which are low-value, while the business really needs them to deliver value faster, and come on, good enough is good enough!
There may be others in the organisation who could provide a variety of useful inputs into design and technical decisions: More experienced developers; Polyglot developers; Specialists, including DBAs (who may not necessarily be in the scrum team); Managers, who may be cynical and may have seen over-ambitious or wrong-headed architectures go awry too many times.
But it's not just about getting input from people with valuable experience. More than this, isn't it fundamentally sometimes necessary for management (at any level) to be able to say "No, this way of implementing it would be a bad idea. Do it this way instead", or at least "No, you can try that later if there's time, but do it this simpler way initially"? It seems to me that Scrum is too idealistic in this respect. I know that this does happen, obviously, but to say that because of this interference "your organisation is not doing Scrum" suggests that "doing Scrum" is not desirable in such cases!