[hal9000xp]

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc.

These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done.

Please, do not point me at agile manifesto.

To me agile looks like totalitarian sect which constantly preaches flexibility and freedom while swiftly punishing anybody who ever dare to deviate from strict daily rituals and mantras.

Dry definitions in agile manifesto means nothing in real life. What's actually important is a context which created by people who adopted it.

Agile/scrum is biggest cargo cult I've ever seen in my life.

[NAHWheatCracker]

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).

[dasmoth]

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.

[adrianratnapala]

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."

[dasmoth]

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.

[jaytaylor]

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.

[okreallywtf]

I think Dave Thomas[0] made some great points recently [1] about what Agile (as a noun) has become and I think it addresses some of your complaints. Note this isn't just a repeat of the agile manifesto, it is him discussing why he hates what Agile has come to mean to a lot of people and it sounds like his grump-level closely matches yours.

The jist I get from it is that agile has become an Enantiodromia[2] and has in some ways simply replaced the problems it was there to fix. That doesn't mean it has to be that way, but thats what happens when people take something and create a religion around it.

In my company we call our process "agile", but what that really means to us is to do the minimum amount of analysis we can to develop the features that the customer actually wants, and when they realize what they thought that they wanted was not really what they wanted, we can change it without wasting massive amounts of time. If we find that our process is causing problems for the devs, we tweak it. When we find we're not doing enough analysis in some situations, we try to improve those situations. No buzz words really, just what is best for us and what is best for the customers.

[0] https://en.wikipedia.org/wiki/Dave_Thomas_(programmer)

[1] https://www.youtube.com/watch?v=a-BOSpxYJ9M

[2] https://en.wikipedia.org/wiki/Enantiodromia

[UK-AL]

You haven't seen cargo cult until you've worked in an organisation with a pmo, and tranditional project management.

I had to literally write a 5 page business case for relatively small features that takes more than 5 days. You then had to get it approved by the pmo board. These people have no product management skills either.

Once it's a approved I have to write a full plan and schedule.

Companies like this exist.

This is what agile was a reaction to.

[klenwell]

I've seen 50-page project specs written before the dev team even new there was a new project. But PMO board. Ouch.

At the other extreme, you have your process-adverse adhocracy where your brilliant new lead developer unilaterally decides the first step in fixing the latest issue with your existing CRUD application written in PHP is to write a new Node framework.

Meanwhile, junior developers are getting bombarded directly by anyone in the organization who encounters a problem while using their keyboard.

Companies like this exist. Maybe not quite this extreme. But I've encountered a few variations on this theme and they've given me a deeper appreciation for agile concepts and terminology.

[dullgiulio]

The problem is that the companies that "went agile" just added some cargo cult practices they learned by some Agile consultant /in addition/ to the old practices you describe.

You know, I am sure many of those Agile consultants that big companies hire don't even know what the Agile Manifesto is.

Agile is not agile.

[Angostura]

This can actually be very useful as it insulates your dev team from some VP wandering across and demanding a pet feature be implemented. The VP has to negotiate the PMO board first

[UK-AL]

A product owner in agile can do exactly the same without the overhead.

[tootie]

Anyone who traffics in buzzwords without adding value is the problem. Scrum is fantastic when you understand the why of its process instead of just following the rules. If you schedule scrums and sprint planning, then accept ungroomed stories, change priorities, deliver without testing, then you are doing it wrong. Really disciplined and experienced teams can follow the intent without the process, but more often than not you need rules to keep everyone aligned.

[k__]

Isn't scrum what happend to XP after managers mangled it?

[tootie]

XP was for developers. Scrum expands it to product management and ownership. The biggest benefit to me isn't developer productivity, it's the ease with which we can communicate progress to stakeholders.

[crdoconnor]

If it truly worked you should be able to just follow the process.

IME tech debt gets worse under "scrum done right" and velocity is a bullshit measure. Those two things alone are enough to reject it.

It's a shame because scrum gets, like, 70% right.

[sixdimensional]

Actually, my opinion is that "agile" the way I most often see it is nothing more than a lighter weight variation of what we were already doing with SDLC. Time/cycles are compressed, documentation is not quite as structured, but the basic ideas are similar.

I agree the hype cycle distorts things too much. I think maybe your opinion is a bit too harsh, but - I would think to use whatever technique succeeds for the need and the team, whether more or less formal. So more power to you if the technique you prefer works.

[losteric]

Processes are templates, anyone that treats them as dogma is doing it wrong... a good process simply facilitates effective communication and planning with the lowest possible overhead.

Agile/Scrum/waterfall/etc should be used as inspiration - but the right process is custom built for each situation.

The only thing that really matters is periodically retrospecting and refining - cut the cruft, fix the flaws, and reinforce what's working.

[hollerith]

I see you have "user story" in your list of hated buzzwords. If you don't mind my ignoring the rest of your comment, I'd like to focus on that single phrase. I claim it is ok.

What was going through the programmer's mind when he wrote a particular passage of code is a very useful thing to document. In my user-facing code such documentation tends to look something like "just now as part of an attempt to achieve X, I did Y, expecting to see Z, but I got U instead." Comments like those occur often enough and are valuable enough that it is good for me to have some quick way to refer to the category. Isn't "user story" just as good as any other quick way?

[haukilup]

It seems that you don't actually object to the principles behind Agile or the processes themselves - just people who abuse and force agile processes on others without understanding _why_ these processes were introduced in the first place.

I don't think the terms you listed are just buzzwords, and I don't think people who use them are always going to be bad hires. It's just terminology.

Agile development has worked well at a lot of organizations. When you hear someone use these terms, you should probably begin digging deeper into why they think the framework/processes/whatever worked for their previous team.

[bdcravens]

I've found value in adopting bits and pieces. We have a small team (2 developers, sometimes more) and we're balancing bug fixes/customer needs/putting out fires/new development. Some guidance about where we're going and what we're walking on keeps us from focusing on the wrong things, but at the same time, when there's 2 developers you have to minimize overhead. I use a backlog and "sprints" (just a range of dates really). I assign points to have a bit of a clue (since I have to be able to answer what's on my plate and give some guidance as to when things may be completed). Nothing is sacrosanct: bugs get points the same as new development, since to the business it's all revenue blockers. A sprint is never carved in stone; any thing can be put in at any time, and priorities can be shifted, as they necessarily must. I don't do planning poker, standups, or retros ... daily communication via Slack is sufficient. We have no made up jobs like "scrum master". To me it's just a framework, in the same way that TDD or MVC are. You adopt pieces that help you get shit done, and ignore the pieces that get in the way of getting shit done.

[sixdimensional]

Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method.

I'd be curious what software engineering process you'd prefer then, for your own company?

Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of quality due to standardization of process and method.

[johnrob]

Small batches. What can I do today, that will demonstrably put us in a better position at the start of tomorrow. Ideally should result in deployed code to production, but not always (e.g. research).

Ironically, you could argue this is agile with one day sprints - I wouldn't disagree much.

[scarface74]

Would you rather be in a situation that before any real work gets done you have to have a "project charter", 3 months worth of requirement gathering, three months worth of development and user testing and find out at the end that your delivered product is completely unusable by the people you were developing for?

"Buzzwords" create a ubiquitous language (a Domain Driven Design buzzword). I can change companies and if they are using those "buzzwords", I know what they mean.

[dragonwriter]

> "Buzzwords" create a ubiquitous language

No, that's jargon. Buzzwords are distinguished from jargon by being language that has become semantically ambiguous (possibly even semantically null) through pervasive inconsistent use, particularly in marketing.

[Waterluvian]

"scrum master" is the one that really grinds my gears. Ive pretty much stopped doing all the jira nonsense and let my productivity speak for itself. I've been left alone about it.

Others here have more thoughtful opinions on the whole thing. I'm just kind of annoyed about it all without the energy to try to formize what's wrong and why. Just let me engineer.

[nulagrithom]

What do you propose as an alternative?

[acdjuiamadfn]

I cannot "upvote" you enough.