Are empty/misused buzzwords harmful? [closed]

Question

I work in a very small company, but I've seen this phenomenon before, to some degree even at all companies I've worked for:

Officially, we work in a Scrum framework, including common planning meetings, daily scrums, retrospectives and sprint demos. There is no formal hierarchy inside the team, and the founder of the company is formally the product owner ("just a team member"). This is not about whether Scrum is a good choice or not, but it is clear that we have not implemented any of the Scrum concepts except for using the terminology. In some cases, some Scrum anti-patterns are implemented 1:1.

I don't want to discuss Scrum implementation here either, but some observations to illustrate this point:

• retrospectives are largely used to criticize our product; action points are about new features and bug fixes
• the product owner assigns every task to individual engineers
• estimated story points are converted directly into duration
• in the daily scrums, every team member reports what they have worked on yesterday
• the Scrum Master role is (implicitly) expected to be picked up by a team member, on top of his daily tasks
• [...]

For me, this way of working is clearly dysfunctional, although possibly not worse than in many other companies. However, even though I am not a Scrum-aficionado in general, I am very annoyed by the misuse of terminology. The examples on top were only a few, basically every Scrum term is "interpreted" so that it fits the desired way of managing.

I just use the Scrum example because it is present in my current workplace, and it impacts the organization of the entire team. I have seen unrelated cases of such terminological confusion in other companies, e.g. where "Test-driven Development" meant to actually implement automated testing.

It seems like other colleagues are not that annoyed by the particular point of terminology, they rather say things like "Yeah, Scrum is annoying." Maybe they just execute what their manager says and ignore the whole reasoning behind it.

For me, however, these continuous misunderstandings are highly frustrating because it feels like I cannot propose any change. Not doing "Scrum" (his version), is also ruled out as an option in direct talks; proposals to change the way we work are mostly rejected because we do "Scrum".

I think the hard point for me is that the terminology issues make open discussions extremely difficult. We use same words for very different things. However, saying that a term really means something different is typically perceived as very confrontational (even when said very diplomatically), even more so when giving sources. I think that is because it implies that the other party has not understood the concept.

As a senior team member, I am officially expected to push for positive change, and I personally also don't want to just execute orders. Furthermore, I see that we are highly inefficient as a team/company, and all team members are frustrated to some degree, so change is necessary also for the sake of the company.

Am I overly dogmatic regarding terminology? Am I actually looking at the right point, or should I just play along with it? I perceive the usage of these terms as an excuse for bad management, but I (naively?) hope that implementing concepts by the book (e.g. Scrum) would be a good start for improvements. I don't mind variations, but I am missing a common starting point.

Answer 1

My two cents, I don't think it's very useful to have philosophical arguments about whether some current practices are done according to the SCRUM-scripture or not. Why not just argue why some things can be done better according to you? Instead of arguing that your way is the actual SCRUM-way as envisioned by it's founder. I think the goal of an company or team should be to do things as good/smart/efficiently as possible, not to implement some methodology in the "right" way.

Answer 2

Are empty/misused buzzwords harmful?

Yes. It's very harmful in the long term. It stands in the way of improving processes. Also sales and marketing teams can pick up on them and relay them to social media and clients.

In my last company this happened, and clients ended up being sold things we didn't offer.

We also had problems with management. Terms like Agile and Sprints were thrown around, but the way we implemented them was completely wrong.

I think this usually comes from misunderstanding. A "little knowledge is dangerous" type of thing. It's easy to read a little bit about Agile and think you get it, not realising it's a lot more complicated and requires experience to implement correctly.

As a senior team member, I am officially expected to push for positive change

Not doing "Scrum" (his version), is also ruled out as an option in direct talks; proposals to change the way we work are mostly rejected because we do "Scrum"

This is what you need to start doing. Start pushing for change.

You can request meetings to discuss process improvements. You need to point out the processes you have now are not efficient... Give examples. You also need to point out what is, and what changes could be made and how they would positively impact the team.

Discuss with colleagues as well. Managers can't avoid the situation if everyone is saying the same thing.

If your managers/bosses wont listen, or refuse to have these meetings, there isn't much you can do, other than moving to a company that implements them correctly or is open to change.

You could start making changes yourself, and lead by example, but I can't recommend this. I've tried it. People are inherently lazy and would rather continue with a current inefficient processes than put in the work required to make the change to a more efficient one. You also risk giving yourself more work and responsibility, and being the scapegoat when something goes wrong because you didn't follow current processes.

Answer 3

Judging from one of your comments, I think you might have a different problem from the one you're describing: perhaps your team just does not care about improving in general, being it "correct scrum" or otherwise. With it in mind I'll split my answer in two based on my assumption being right/wrong.

If what I propose is indeed the reality, there's not much you can do. Even if you had magic powers and scrum was overnight implemented by the book, the attitude will be the same. Cerimonies will be half-assed, won't bring any value, etc. Knowing that, you need to work in the core problem and the processes will naturally flow into a more helpful state.

Given you're theoretically in a "pure horizontal" organisation and you don't need to worry about higher ups blocking initiatives everywhere, you can try and organize workshops and team building exercises (there's a slew of helpful advice in this very SE regarding this issue).

If it still doesn't work... Well... IT isn't really an opportunity poor environment.

---

Now for the other option: your team's problem is actually that scrum isn't implemented properly.

This is a slightly easier issue to solve, assuming you know what added value scrum brings to an org. Just try to "hijack" ceremonies in a way that it shows that value to everyone else. Examples

• For retros, do not join the "bash the product" bandwagon: just arrive with a well planed list of things you know your team can improve upon, with clearly defined problems, and even clearerliest defined solutions
• For tasks assigned 1 to 1 don't be afraid to challenge those decisions, when and if it makes sense. If you notice someone is lagging behind while other's have nothing on their hands, reach out to them and propose changes that might benefit both parties (believe it or not, people do not like twiddling their thumbs all day). This is supposedly encouraged because someone should autonomously take the role of scrum master anyway. If this isn't even an issue, don't fret it. Processes are only as useful as the value they bring to the team. Even if "pure scrum" (if that's even a thing) disallows it, as long as things run smoothly, that's the end goal.
• Story points are converted directly to hours: Again, no harm no foul. As long as you have a sprint budget (be it hours, effort, amount of donuts required per task, ...), you plan sprints accordingly and estimationAmount < sprintCapacity, ¯\(ツ)/¯. You need to think to yourself: how is this detrimental to the team and how will follow scrum fix it?
• Dailies: again, monkey see, monkey don't need to to. You can make dailies more useful for yourself and others may follow suit. Describe issues you had as long as the team can help you. Tell them what you plan on do that day and expected issues. If your issues can be quickly addressed right there and then, others will see the value and will follow suit. If you cannot bring any value to yourself, maybe "scrum by the book" isn't the right fit for your team anyway.
• Rotating SM role: if you follow the above guidelines you're already doing more than 90% of SM's I met in my career.

---

Final remarks: Either option will obviously take work. A loooot of work. People do not change overnight, even if it eventually benefits them. You need to be prepared to bear that work if you want to see any changes.

Answer 4

I think buzzwords are harmful as soon as they become buzzwords and you lose the meaning behind it. Scrum is not a buzzword as such, it becomes a buzzword in the mouth of people using it without knowing what they mean. To me "buzzword" has some pejorative meaning. For example if your company was efficiently implementing scrum principles, you probably wouldn't consider all these terms buzzwords, just the names of what you do.

When I read "proposals to change the way we work are mostly rejected because we do "Scrum"", I know that in the mouth of that person, Scrum is a buzzword because the sentence describes the opposite of Scrum. Retrospectives are exactly about changing (improving) the way we work each and every sprint.

So yes, I think buzzwords are by nature harmful, because of the people using them as "buzzwords".