Hacker News new | ask | show | jobs
by NAHWheatCracker 3238 days ago
I used to think that the words you mention are the problem causing so much bureaucracy. My thinking has changed such that I don't blame the vocabulary, instead I blame the people who abuse it.

There are genuine people who use these buzzwords you mentioned because it makes it easier to discuss concepts/aspects of project management. It's faster to say "user story" than to say "an informal, natural language description of one or more features of a software system" (from Wikipedia), or to describe all the additional context that "user story" evokes in a person.

You're right that concepts can be misused and end up in a totalitarian environment. That's because the people at the top want it that way. In my experience, they don't want to (or can't) dive into the context of all of their teams and prefer to seek a one-size-fits-all approach.

At my last job there was a new CTO hired about a year before I got there and he started a Scrum initiative on the whole organization. They hired a PMO (Project Management Officer) and a slew of Scrum Masters. Half of the Scrum Masters I worked with were genuine people who wanted to help their teams and knew that by-the-book Scrum wasn't going to work. Those Scrum Masters left within a few months because they kept being told to force policies that were doomed. People argued, but the CTO and PMO didn't budge and problems never got addressed.

If you ever create your own company and you want to prevent bureaucracy, I think focusing on vocabulary will not be very effective. Focus more on keeping your ego in check, constantly push flexibility, and test the unusual ideas of your workers. However, if you have run-away success, any of your own attempts to wrangle bureaucracy will be hampered by size. Delegating anti-bureaucracy could be hard (and counter-intuitive).

1 comments

There's some truth in this, but I don't think "good agile" is totally innocent. In particular, they always seem to be uncompromisingly team-focussed methodologies (a lot of stress on the "...and interactions"), with little scope for individual creativity and problem solving.
And yet it is from the Agile mantras that I learned how to keep meetings ruthlessly short. "What did you do, what will you do, what's blockng you."
Not denying that. But those questions are specifically aimed at preventing people "going dark" even for a couple of days. On projects which require some exploration and creativity, I don't see that as a positive.
This is a perfectly valid perspective to have, and I totally understand the apprehension and aversion to management buzzwords.

If I may share an alternative possibility..

It often comes down more to communication styles and the individuals involved. It's still possible to do exploration and answer the questions about what's done / doing / blocking. You could say "I learned X won't work, now I'm exploring Y, and currently debugging Z". The only time this would be problematic is in scenarios where the leader is not supportive of honest communication about activities, in which case it may worth asking why you're spending your life / time underneath such an individual.

In general I'm a strong advocate of tight feedback loops and frequent communication in a team. There are many benefits, including helping ensure everyone has access to the support they need to be successful. The result of these tight loops sometimes also translates to deciding to set someone loose for a[defined] period of time to focus their energy on researching creative solutions or just jamming on something without distractions.

P.S. - Regarding "going dark": As a manager I can understand why as a general rule of thumb that managers pose issue with this.

The common, crappy scenario goes like this. An individual goes dark, then comes back with nothing of consequence to show for it or any evidence that they tried to do anything. Now valuable time has been squandered, while the rest of the team was hard at work. This leads to an array of harmful effects for all involved (the manager, the team, and individual worker).

Even if you are super responsible, fear and trauma from past offenders could still be a trigger for some managers.