Hacker News Reader

From my personal experience across multiple jobs: For every company that tries to embody the old Agile Manifesto there are a dozen who've simply plugged The Latest Trendy Management Practice into that module slot and are continuing business as usual. No, thanks.

Right, and for every company who advertises ‘competitive compensation’ and means it there are a dozen whose idea of competitive comp is that they’ll match an offer to retain you later.

You do need to filter through some BSers to find a good job but that doesn’t mean any company that claims anything good about themselves is lying.

Unfortunately it’s become a high-confidence signal that shenanigans will be ongoing.

I use this as a signal of avoidance: not interested in your varied way to try and manipulate SWE labor and squeeze another once of productivity out or pass off your debt in the form of my time at the cost of my sanity. I know many others that do the very same. Perhaps it's my loss, it's a risk I'm willing to take due to the number of bad apples associated with such practices.

I'm not sure what this kind of cynicism actually gets for you.

If you approach any job ad with the assumption that whenever they try to put a positive spin on the working environment they offer, they really mean they'll manipulate your labor to squeeze out productivity at the cost of your sanity...

... why would you work for anyone?

You're assuming that agile is a "positive spin on the working environment".

In 11 years of professional work, it's only ever been used as a weapon against the development team.

Spot on. Often it feels like a cult, but even more often is used as a micromanagement tool.

This has nothing to do with agile practices. Micromanagement is micromanagement. The people you are apparently working for and with will micro manage regardless of any process.

I also suspect that you do not actually work in a team. You probably work with other people that are loosely grouped together. I doubt you are actually working together on a common goal though, if you do not see value in standups for example. If there's no value in knowing what your team members are working on, you are not working closely together,you aren't helping each other etc.

I suspect you have a product owner that sees standup as a progress report to them and that tries to exert their micromanaging power through it. I also suspect that you don't have a Scrum master that protects the team from this rogue product owner.

I would take such a PO to the side and explain to him that if he doesn't stop this practice they will soon be disallowed from being in standup and that they have one chance to stay in standup and at least listen. Meaning unless asked a question by a team member they better keep their mouth shut.

Am I at least somewhat close?

> I doubt you are actually working together on a common goal though, if you do not see value in standups for example.

It sounds like you're assuming the only way to sync up with folks is a stand up, which is just ridiculous. I'd even make the argument that if you think you need a stand up so that team members actually communicate with each other then you're not working on an actual team, you're working with other people that are loosely grouped together. Any good team I've ever worked on, people just organically collaborate as needed. You don't have to wait for some arbitrary sync-up time to let each other know what's going on.

In general, I'm not necessarily against stand-ups, as long as they're quick and don't turn into status meetings. In my mind, a perfectly reasonable stand up could be "does everyone know what they're doing? Does anyone need help?" and if the answers to those are "yes" and "no" respectively, then we can be on our way. But more often these things turn into minor status report meetings, where everyone starts saying "this is what I did yesterday; this is what I'm doing today..." and often those details are not relevant for everyone on the team and could just as easily be communicated elsewhere in an async fashion.

I feel like a lot of things like stand-ups exist for the lowest common denominator teams. Bad teams don't organically communicate, people slack off if you don't micromanage them, etc., and so for those teams you NEED a stand-up. But then it gets forced on everyone and is a drag for high-performing teams, and good people end up leaving because they just don't want to deal with all the BS. So you end up with a self-fulfilling prophecy where what you're mostly left with is bad teams and so it feels like stand-up is necessary or is working. It's kind of maddening.

They're putting it in their job ad. It's fair to conclude they think it's a perk.

> I'm not sure what this kind of cynicism actually gets for you.

Not OP, but cynicism against agile get me (somewhat) avoidance of the most toxic workplaces, which is what agile is.

Because you have to? Your other options are to be born wealthy, start an independent business (which also usually requires up front capital), or live out in the wilderness.

As the alternative, you try to find positions that don't look like they have a pile of spin buried in them that seem to be hiding something. You look for red flags and then interview the set of employers that is also interested in interviewing you.

You can reduce the filter and wait for the interview processes to reduce false positives but from my experience, being cynical is a good filter to save me time from working in toxic positions at toxic companies. After interviewing and working in business environments, you learn more and more of the spin techniques everyone seems to use.

It's interesring how being critical of business ads is viewed negatively, yet it's perfectly fine for businesses to have full day interview processes, background checks, resume filters, skill tests, etc. Hiring businesses obviously don't trust you and your advertising, why is it assumed you should trust them? Trust is a two way street and has to be built and business relationships are growing increasing transactional and shorter term which doesn't exactly instill a sense of trust between people.

Sure, just as for every company that actually offers competitive payrates there are a dozen who just say they do. But it's not like not caring about management practices magically makes a company good at them either.

You wrote almost exactly the same thing as the other person who replied. I have to ask (both you and jameshart): What makes you so defensive of Agile? What benefit have you seen it bring? Truly curious, not trying to bait anybody here. My experience with Agile—except when another engineer and I basically stealthed rapid development into a company with 12-month release cycles in the mid-2000s—has been overwhelmingly negative. 45-minute “standups,” major projects given 3 points, every negative stereotype bandied about on HN is something I’ve experienced.

Why do I 'defend' agile?

I guess... for one thing, I have, multiple times in my career, been part of technology organizations that have positively transformed their relationship with business stakeholders by getting the business to buy the underlying truth: building software is a learning exercise; the requirements can and will change.

And the frameworks you have to put in place to make that kind of relationship work, to replace the arbitrary deadlines and deathmarches? Turns out 'agile practice' has a bunch of useful ideas for those.

Teams have limited capacity for 'work in progress'. The upcoming work can be prioritized on a backlog. Loose sizing estimates can help us make decisions about trading off time and features. You can only have one top priority at a time. It helps to let teams understand what problem they are trying to solve, not just tell them to implement a piece of a solution.

That's what I value when I talk about 'agile'. A bunch of useful ideas stolen from scrum and kanban and lean and so on that actually help put developers in a position to solve the right problems in the right way, and get 'management' off their back.

I'm also a fan of daily planning meetings to facilitate collaboration inside teams. I like retrospectives as a way to identify ways for teams to improve how they work. I like short fixed-duration iterations which deliver working code. I like pairing on problems. I like continuous integration and deployment and automated tests written alongside the code. Those are good practices that we, as a small team of developers, can use to help one another do good work, and ship working software.

And those ideas are all also stolen from things like scrum and XP and TDD and devops, which are also all 'agile' practices.

If someone tells me they don't like agile I am confused because... I don't know why you wouldn't want to work on teams that follow those kinds of practices.

I do get that plenty of people have been subjected to environments that use things with the same names as these things in ways that aren't remotely agile. But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them is like saying you never want to use a programming language that has strings because PHP's string coercion sucks.

I find these practices helpful, and better than not following them. I've been lucky to get to enjoy working in environments that use them, rather than have them badly forced upon me.

Thanks for the detailed reply!

I have to say, everything you wrote sounds great. We'd probably agree on more than we'd disagree. That said...

> But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them

It's not that I've been subject to "a bad implementation." It's been multiple, across a decade, ever since Scrum became a thing, really. Disaster after disaster.

I'd also add that most of the effective engineering I've seen (aside from the occasional uber-productive solo code artist) had clear priorities, effective intra- and inter-team communication, and certainly a disciplined retrospective process, all without Agile or Scrum. In the best cases it was self-organized, because we wanted to do good things for the sake of doing good things, and management understood we were trying to do the right thing, and got out of our way when we were being effective. When we weren't, it was a conversation, not school-time lockdown. I don't think that environment can be replicated by process or fiat, which is what the formalized Agile/Scrum of today seems to try (leaving aside the more cynical cases).

So let me put it this way:

Most businesses do not know how to manage software projects. That's not entirely special to software - most businesses don't really know how to manage anything.

Agile tools offer a framework for technical teams for fighting off and thwarting crappy management that doesn't understand how to make software.

But some crappy management organizations are really, really hard to thwart.

Worse, some crappy management organizations have figured out how to neutralize agile tools, by co-opting them and trying to use them to continue crappily managing the software project. Sometimes they do this pre-emptively, neutering one of the only tools a technology organization has to fight back.

I would love to know what else people have had success with as a way to fix crappy management other than setting up a properly agile 'safe space' for tech to happen in.

This makes sense and puts it in a slightly new light for me—as a way of salvaging some productivity, when run by the developers, Agile/Scrum would certainly be better than many alternatives. I guess that’s what we did in my earlier reference, about 16 years ago. I wish it hadn’t become so coopted by the usual suspects.

This reads exactly like someone who's never been on the development-end of an agile team. You could have said you copied this from some promotional material for an Agile consultant and I'd believe it.

Really your only argument is "those companies didn't do it right", but the problem is that if agile is so hard to do correctly then doesn't that mean there's a problem with it?

Weird, because it was written by someone who's been a working software developer for 20 years and who has so far successfully resisted getting shoved into a hands-off-keyboard management role...

Then you've been lucky. Good for you!

We’re hiring

Contact info?

I am a Scrum Master, because I decided that if I can't avoid Agile, at least I might learn to do it properly. So I got some training and read some books. And I was confused, because "this sounds nice, but is totally unlike any Agile I have actually seen as a developer".

Then I took my role, and tried to implement the first thing they taught us at the training... but the management said "no". So I tried a different thing... but the management said "no" again. I asked what's the point of sending me to an Agile training if they override all my decisions, and the answer was, more or less, "we are doing Agile this way". My options were limited to do "Agile" their way, or to quit my role and be replaced by someone who will do "Agile" their way.

So now we are doing Agile the way everyone hates and everyone does, with me in the role of the bad guy. Except our standups are 5 minutes long, because... that's the only part that remained firmly under my control. Otherwise, everything is the opposite of what the Agile trainings and books said. The management made a big announcement where they congratulated themselves for successfully transforming the company to Agile.

From my perspective, this answers the question why "true Agile has never been tried". The people who make the decisions, they want the buzzwords and some of the rituals. They do not really want to give up any of their managing power.

To try the Agile as intended... you would probably have to start a cooperative. Or be a very enlightened founder who can resist the temptation to use their power.

I've seen Agile be hugely effective when actually done. It results in a much better product that's also more suited to what the customer needs, and therefore much more fulfilling to work on. It cuts through many of the most frustrating and wasteful parts of other kinds of software development at a stroke (e.g. endless architectural arguments). I genuinely think it's the best thing that's happened to my career. So it's frustrating to hear people attack it and especially frustrating when it gets attacked for the opposite of what it actually is.

I don't know how to make people stop lying about what they're actually doing (I wish I did), but I don't think it's reasonable to expect any kind of process to work when you do the opposite of what that process actually tells you to do. (And I'm quite prepared to entertain the possibility that an organisation that actually committed to following RUP or Six Sigma or whatever and followed through on it might be better than half-assed non-Agile "Agile". But I haven't found the HN-endorsed "lol no process" to be effective in practice either)

> You’re shooting yourself in the foot by ignoring companies that take pride in offering an agile development environment.

Fine by me. Everything I've seen and heard of Agile (both in the last company I worked at and from others) is that's it's a dumpster fire. It wasn't created by developers to improve development, it was created by consultants to sell consulting.

DevOps is dumb, too.

> Consider the alternative: a company whose ad says “we don’t follow any agile practices” - what would you interpret that to mean?

That they haven't fallen for the hype and do what works for them.

You're hired!

It could also mean that they fall under the other extreme of perpetually outdated over-documentation. IMO the only thing worse than no docs are wrong docs.

Would you say that, perhaps, you value working software over comprehensive documentation?

I get a lot less grief from the people who pay the bills this way.

I can always read source code. Any programmer worth a damn can. Docs are out of sync with the code the second the code changes in any non-trivial way.

However, code always documents how it works (sometimes poorly, of course).

I'll take that as a yes.

So I wonder how you feel about:

Individuals and interactions VS processes and tools

Customer collaboration VS contract negotiation

Responding to change VS following a plan

They're all important. I don't really see the point in chosing one or the other.

You have to pick one or the other when choosing your development strategy. If you focus on customer collaboration, you could end up giving away too many freebee features that should have been feature requests and billed.

If you have a design iteration plan, how do you respond to a showstopper that makes the plan infeasible if you are on a strictly waterfall design plan?

Each has it's trade offs so you can't always pick one or the other willy-nilly or else you don't have a design strategy at all

The code I write is going to be used for 20-30 years, and then when the platform is replaced I assume someone will read the code to see what they have to do to get the system working on the new platform. I have documentation for end-users and documentation for maintenance / troubleshooters and zoomed out documentation that explains the problems and approaches taken, and sometimes justifying any tradeoffs.

If code is temporary then it might not be worth the effort to document, but my documentation is what everybody except one person 20 years from now sees along with the user interface, so for my application the code doesn’t matter and the documentation matters quite a bit!

I was more referring to how the code works and development practices/codebase layout/etc, not end-user documentation.

As a counter-point, i've seen engineer-led Scrum and other agile varients work very well. Low stress, high productivity, high predictability.

YMMV, and sadly the norm tends to be bad practice, but it isn't all like that. Companies with good engineering culture do engineering well.

Companies with a poor culture do most things poorly.

> Companies with good engineering culture do engineering well. Companies with a poor culture do most things poorly.

Very true, but the "good" companies will be good regardless of what methodology they use. And it's rarely a one-size-fits-all approach. They recognize what works and what doesn't, without slavishly adhering to a single doctrine in the face of all evidence.

So... when you're looking at a job ad, what words are you looking for that tell you a place has good engineering culture?

I'm getting that 'agile' is not one of those words, but what words are?

An ad is pretty much useless for that, other than "negative" words (to me) like "scrum", "agile", etc. I'd be looking at the tech stack for things I'm proficient in, or things I'd be interested in learning. Also, WFH is now a critical for me, so it has to be 100% full-time remote work.

I'm indifferent to seeing "agile" in a job ad. Getting a job or client is like dating ... you find out what they mean by their bio over a few dates.

If I ever accept a client or job, there's always a grace period.

I'm so confused by this thread.

It's like I've wandered into a conversation where people are saying,

"You know, my boss tried to give me cake the other day." "Cake? Everywhere seems to be doing it nowadays. What I would give to find a place to work where the boss doesn't make you eat cake all day." "Yeah, cake cake cake, all the time."

And I'm like,

"Er... cake? The yummy thing that's really nice? Your boss gave you cake? And you didn't like it?"

And everybody replies:

"No, you idiot, cake! Smelly, hard, poisonous cake, with glass shards in it as usual."

I'm standing here, with my slice of yummy cake, thinking... are you the crazy ones, or am I?

"You know, cake's meant to be like this: soft, sweet, really tasty?"

"Yeah, that's what consultants want you to think, but cake is actually made of burnt tires and crushed up bottles."

"Your boss gives you burnt tires and crushed bottles and tells you that's cake?"

"Yes, that's what cake IS."

And I can point to all the recipe books for cakes, and show you the cake I'm eating right now, and you'll all still tell me:

"Well every cake I've ever been given smelled of burning rubber and made my mouth bleed, so I don't want to work anywhere that advertises that they give employees cake any more." "You sound just like the last guy who gave me cake."

I mean, I get why that kind of experience might make you cynical, but I don't understand this desire to wallow in the belief that anyone who tells you it doesn't have to be like that must be lying or selling something.

"And chocolate's awful too."

Really? The same asshole who has gaslit you about what cake is has lied to you about chocolate too?

I'm so sorry for you. Please. Let someone help.

Have some cake.

> I don't understand this desire to wallow in the belief that anyone who tells you it doesn't have to be like that must be lying or selling something.

Because literally every time we've encountered cake it's a painful and disgusting experience.

It's more like you've been given something that's been called cake, but is actually not cake. Whoever baked it realized that the recipe for cake could never work, so they changed it into something that would, and told you that was "real" cake.

Yes, I believe you have been subjected to that abuse.

But... the point of my metaphor is: cake does exist. It's real. You can make your own! The recipes are available! They do work! The fact that people have convinced you that cake doesn't exist is a reflection on them, not on me.

You are trying to convince me - a person who is eating a cake right now - that cake is a lie. And for some reason you seem really angry with me about it.

Angry? That's an odd assessment. I'm angry at the people that make and sell LieCake, and how they've deluded you into thinking that cake is a sweet, tasty treat. The key point for you to take away, is that it's remarkably hard to make an edible cake. It should be clear that you're in the minority (in this thread) of having received something edible when many others have been given burnt tires and glass.

Wow, I would love to work somewhere with waterfall requirements-gathering processes and change-control documents. Across several employers, I've seen a lot of misdirected work that just makes future work harder.

Now of course the response is, why would I want to put up with that bureaucracy - won't it backfire on me? But it shouldn't be bureaucracy, it should be something driven by the engineers with the goal of shipping better products.

Which is the problem with advertising agile. When a company says they follow agile, what they often mean is that there are people whose job it is to make sure the agile process is followed, effectively making their own agile bureaucracy. That's what scares people.

I want to know that the company is going to get out of the way of practitioners and let us do big-design-up-front if we in our judgment as practitioners determine that a specific situation calls for it.

I once worked at a place on the opposite side of the "process" spectrum:

No source control

No bug tracker

No formal QA

No versioning or release process. When a customer needed a build they just took whatever happened to be on the lead developer's PC at the time.

No roadmap planning process. The CEO would walk into your office and spout off about some idea for the product, and that's what you'd be working on next.

And I can assure you the did not do agile or scrum. Wasn't a really great place to work. Very chaotic and everything was a fire to put out. Lots of turnover and burnout too. Would not recommend. There's a sweet spot in the middle of the 'process' spectrum.

I interned in the software process group for a defense company building sattelites. It had the other extreme of the process spectrum- true waterfall/CMMI processes in place, but they were so painful that people just did work and then figured out how to claim they followed the process afterwards. They actually had a couple good processes that I walked away with (different levels of formality for code reviews, structured and a risk based QA processes), but overall it was about frustration and a molasses like movement. I was glad to end up on consumer software for a while after college.

I disagree. The only shooting-myself-in-the-foot I've done is to accept positions at companies with agile.

It just doesn't work.

"self-organize" - oh, sooner or later you're in for a treat. Agile coach: "Everybody go to the meeting room, you're going to self-organize. This is how you're going to do it...". I've not yet met an agile coach with the intelligence to parse what they're regurgitating. The only time I've seen agile work was pre-Agile when it had nothing to do with Agile.

Then you've been with the wrong ones. Here's what my favourite agile coach does first thing in his courses. I've seen him consistently do this over many many times I've seen/participated in his courses:

He runs a self organization exercise!

You laugh now because you imagine it the way you described it.

Well actually the first thing he does is to appoint someone as 'the worst micro manager in the world' and asks them to sort participant's by number of years of experience with agile development. He times this with a stop watch.

When that's done he simply states that he wants participants to self organize standing next to each other sorted from one end to the other by number of years of experience in software development now. He then stands somewhere in the middle of the room himself and just starts repeating over and over "21 years, 21 years, 21 years,..."

Usually it takes a little while for people to 'get' what he's doing but he stoically just repeats his 2 words.

This is timed too of course. It's interesting how much less organized the second round seems when you are in the room watching this. But it's so much faster and gets the point across brilliantly if you ask me.

If they're really interested in talking about how agile they are, the signal to me is that this is a management-run company, not an engineer-run company.

Plenty of engineer-run shops are lowercase a agile, but it's not something they bring up constantly.

> getting out of the way of tech practitioners

Agile is the literal exact opposite of "getting out of the way of tech practitioners".