One of the most essential part about Scrum is that it aligns the understanding across all the stakeholders, including business owner, customer, designer, developer etc. Hence the meeting, prioritization, backlog, daily standup/daily write up as development process artifact etc to focus on the priorities that create the most business value under flexible scope, fixed time and fixed money.
scope, time and money are the three variables of a development process. At the end I think the author is proposing with the process for a flexible scope, flexible time and flexible money, which often is a internal project that doesn't have direct business applicable value. In this case, the author should really just break into another side team without business owner and, or even without project owner and simply use Kanban as the solution, instead of sticking around with Scrum.
I believe every process has its shortcomings, but instead of pointing the wrongs, I'd appreciate more if the author describe what the situation/stage/type of this project, and why scrum doesn't work in this case, and how a different approach can optimize the outcomes.
Except most of the 'stakeholders' don't give a fig for what the Engineers value. Like technical debt, robustness of the solutions, relieving bottlenecks both in code and in development.
So Engineers get herded into little incremental projects that management can swallow as having 'business value'. And the herd marches toward the cliff as the code base wanders around the solution space but never gets fundamentally sound. Anyway, that's my jaded (from experience) view.
No process will solve the lack of understanding. Also, this goes both ways since engineers frequently don't give a fig about business priorities. Sometimes your refactor isn't really that valuable and is costing the company money.
If you have a culture of trust between departments, you should be able to have honest conversations.
That's exactly the call that gets made again and again, by managers. They rarely value code quality; so easy to dismiss with "that's just a refactor". Converse all you want. Business folk are not going to believe that Engineering isn't foolish and just "costing the company money".
That's the culture difference between working in a cost center and working in a profit center. If you just tell business our code is messy and we want to make it nicer, they will tell you to fuck off. Tell them you need to reduce operational risk and maintenance costs. You need to meet each other halfway.
