I agree with that. But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to. Bad scrum practices are, in my experience, very often the consequences of the devs themselves.
I'm a scientist working in the R&D of my company, and I'm involved with business people (to know what the company needs and what will help) and the software development (to follow up to see the PoC properly implemented and put in production). While I see business people trying to follow and understand the need of the software side, I keep seeing the software side considering that trying to follow and understand the need of the business is not their job. They just want perfect "requirements", and when they interpret them in a way that is obviously not what was needed, they just say "the requirements were not written precisely enough".
I even remember in my previous company the software team joking that they redirect the company emails to the bin inbox automatically, and then complained that they were made aware very late and did not had their say in some decision. Because I have read these company emails, I knew that these decisions were discussed in time and that they have requested inputs from everyone from the company (and they took into account my feedback). This was so ridiculous from the outside, but from the inside, they were fully oblivious of how stupid they acted, they were convinced the problem was "the others". The lesson is that, now, when I have something to complain about, I first investigate if my own behavior is not also responsible of the situation.
Most places I've worked, there is a clear separation of roles between the Product Owner (whose job it is to handle the business case, gather requirements, understand the "why", and decide the "when" and "what"), and the engineering TL who is merely in charge of "how".
At a few places, the TL does it all: business case, requirements, project motivation, schedule, AND the implementation. A lot is asked of that person, but it results in IMO better coordination and execution, because it's not a constant battle between "engineering vs. product". Well, there is a battle, but the battle takes place entirely in the TL's head, so it's faster and less visible.
In order to do it the second way, you need to hire engineers who also can manage the business/requirements side of the project. These people are significantly harder to find than engineers who just read a requirements document and implement it.
That's correct and that's the point: the bad scrum situation is sometimes in place because the TL does not do it all, either because they don't want to or is not able to.
Sometimes, it is because the owners or the managements do not let them to. Sometimes, it is because when the owners or the managements gave them more opportunities, the engineering TL did not use these opportunities and the owners or the management had to fill the gap.
As you said, taking these responsibilities is difficult for the TL and is asking a lot, so I don't think it's fair to expect it to be done systematically.
On the other hand, on my own experience, it is not very difficult to understand the technical aspect. It does not mean "being able to code", it just means "the devs explained the situation and I understood it". My experience being in the middle is that devs are usually worst at understanding the business side than the business side at understanding devs. So I really think that it's unfair to say there is only two ways: either the TL take everything in charge and the decisions are good or they don't and the decisions are bad because non-devs are obviously idiots.
Well, technically, if you show them the door, you failed to get them implied in the business aspect.
But also, the bad scrum situation exist EXACTLY because it's a strategy to push devs to get implied in the business aspect. Or rather, the "good" scrum situation evolves into a bad scrum situation because the devs did not took the opportunity when pushed to get implied in the business aspect.
I also find it strange and funny that some people are being so upset that a bad scrum situation exists, which is way less violent that showing them the door. If the bad scrum situation is too bad for you, you can always leave, which is equivalent to showing you the door. But hopefully, you can also take the initiative to be more engaged with the business side, which will have the consequence of making the bad scrum situation disappear. It is strange to blame people who try to avoid the most drastic situation of firing people.
> Well, technically, if you show them the door, you failed to get them implied in the business aspect.
I don’t think it’s a failure to recognize the problem and solve it by replacing the ignorant person with someone who cares. It has certain price, but it is better than supporting toxic culture, because toxic culture will inevitably increase churn and you will pay more.
You reacted to my sentence: "But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to"
What you say is that you cannot force them, but you can replace them. So you just say my sentence is perfectly correct.
Not sure what you bring to the conversation. Sure, a manager can fire a dev to avoid the toxic scrum situation (that's pretty obvious). Identically, a dev can quit to avoid the toxic scrum situation. Or, even better, the dev can grow up as a person and as a professional and try to make things work by doing their job that involves understanding the business situation too.
The latter seems to me to be the most sane one, and firing seems to me to be pretty drastic.
My point is that the dev has some responsibility in the toxic situation and it's just being ignorant to not notice that.
And, yes, it's sad that some managers don't do their work well and decide it's easier for them to have a toxic situation than taking the risk of firing someone (which can be a long process and can easily backfire on them, especially if the dev in question is not mature enough to understand they are part of the problem). But why these managers would be more guilty than the devs who created the toxic situation in the first place? Somehow, it's like devs have the right to be bad but managers should all be expected to be perfect. Or that devs have the right to think "not worth it, I will not take more risk or spend more energy to fix a toxic situation, I'm just going to ignore it and it can be someone else problem" but the managers don't have that right.
Oh, and funnily enough, in other discussions, some people answered that it's the responsibility of the manager but not of the dev. The same people who were complaining to be micromanaged and were asking why the company is not trusting them to take responsibility for the good operation of the company. Or that they could easily do the manager's job. Or even said that managers are a useless job anyway.
I'm a scientist working in the R&D of my company, and I'm involved with business people (to know what the company needs and what will help) and the software development (to follow up to see the PoC properly implemented and put in production). While I see business people trying to follow and understand the need of the software side, I keep seeing the software side considering that trying to follow and understand the need of the business is not their job. They just want perfect "requirements", and when they interpret them in a way that is obviously not what was needed, they just say "the requirements were not written precisely enough".
I even remember in my previous company the software team joking that they redirect the company emails to the bin inbox automatically, and then complained that they were made aware very late and did not had their say in some decision. Because I have read these company emails, I knew that these decisions were discussed in time and that they have requested inputs from everyone from the company (and they took into account my feedback). This was so ridiculous from the outside, but from the inside, they were fully oblivious of how stupid they acted, they were convinced the problem was "the others". The lesson is that, now, when I have something to complain about, I first investigate if my own behavior is not also responsible of the situation.