[m0nty]

> without having to play the development workflow game with the daily standups and so on?

It never used to be like this. I think management has reacted to the traits they perceive in programmers - get distracted too easily, work on things that don't need doing, take too long, cannot provide work-time estimates, etc - by putting in place this micro-managing approach: "only do it if it's on the kanban and tell us each and every day what you have done and will be doing". I know agile, etc, weren't designed to do that, but that's what they've been used for whenever I've been subjected to them.

Programming and dev-ops used to be fun, self-directed, creative work which kept me interested for a couple of decades. Now the pace of change (much of it unnecessary or over-sold) and the constant micro-management have me looking for other things to do.

[Clubber]

I believe Agile (at least as thought of by management) is designed to make programmers interchangeable. If programmers are interchangeable, they are easily replaceable.

We just started doing "by the book" Agile with daily stand ups. Now that you mention it, it does feel like I'm being micro managed. Put in your time every day so we can email everyone the burn down chart. Lets add some more pressure to the job if you are behind a day. There are no milestones, just an endless grind. I don't know why programmers don't push back against that stuff.

[meddlepal]

Push back and you'll just be replaced by someone younger or more naive or willing.

At the end of the day programmers are mostly just factory workers of the 21st century. The best ones are perhaps closer to the mechanics of the industrial revolution.

[d0lph]

Except with amazing pay, serious benefits, and better working conditions.

[Grishnakh]

Compared to factory workers of 50+ years ago? Certainly.

Compared to programmers 25 years ago? Absolutely not. The pay is worse (inflation-adjusted), and the working conditions are far, far worse (see: open-plan offices).

[mikestew]

(My apologies for crappy formatting. All I wanted was a bulleted list. Wasn't that doc'ed in the FAQ or something?)

Let's see what I was doing 25 years ago:

    * Private office with a door that closed.

    * Status updates mail to $SOMEONE once a week that were mostly auto-generated from the tools we used. Took 30 seconds.

    * Sat down to a chunk of work uninterrupted for long periods of time because no one was micro-managing me or bugging me on Fashionable-Chat-App-of-the-Week.

    * Used development tools that had a half-life measured in years, not months.

    * Got to really, *really* know my tools because they weren't swapped out for the new hotness every six months. Man, the ways I used to abuse FoxPro bordered on criminal. I can't do that these days since the tools get swapped from under me so often.

    * Was paid well, and treated with professional respect. Sometimes a collared shirt was required, but I didn't mind when everyone else had to wear ties.

    * Was provided with good equipment, often without asking. "I have a quad-core server box with an assload of RAM for a...mikestew?" "That's me, but I didn't order it." Boss: "oh, thought you might need that for multithreaded testing." Thanks, boss!

    * Went in at 9:00, went home at 5:00. Every day.

Today:

    * Today I'm sitting in a retasked storage room because I refuse to sit at the "hotel desks" (note that I'm currently a consultant, so it's not *as* egregious. But 20 years ago, clients that wanted me on-site provided a desk or sometimes an office.) My last full-time position was in an open office plan sitting next to people that literally (and I use that word literally) spent more time talking about the fucking Seahawks than they did working.

    * Daily stand-ups to justify my existence.

    * Treated like an interchangeable line worker.

    * Working on the cheapest Macbook Pro that Apple would sell the client. With a 120Gb drive, I spend at least a billable hour a week trying to free up space what with Android/iOS dev environments and the multi-gig simulator images. But, hey, at least they saved $100 on the cost of the machine!

[toddan]

So much this. And the biggest fools are the programmers that believe that they are unique wizards working magic and being special. They are simply factory workers working under an illusion.

[fastcars]

It is probably also about managers protecting their positions and removing power from those below them.

[Chris2048]

> work on things that don't need doing, take too long

These are also traits of junior developers, who now get boosted into non-junior roles due to demand for developers.

Hiring cheaper juniors and trying to micro-manage them into intermediates... The same approach suffocates eventually when "unaccounted for" tech debt creeps in.

That said, there is also something to certain devs wanting to play with shiny tech (and build their cvs) rather than the best tools for the job. This, along with " cannot provide work-time estimates" point to the need for some senior role who can management overall project development, including goals, estimates, planning and tech stack choices; and this has to be a senior technical role, not a MBA-ed middle manager with a list of methodology-derived rules carved into stone tablets.

[JoeAltmaier]

Yeah Agile is the assembly-line version of software development. You're reduced to optimizing effort for your very local problem space. And its a grind. The 'sprint' is well-named though - you constantly race toward another crappy feature done with minimum effort.

[digler999]

I think it's just that the business wants to know where their money is actually going (and they have every right to, it's effectively their money, or managed under their auspices). and unfortunately agile is one way they can accomplish that. It's unfortunate because it costs a lot of developer time to go through the motions, and we are the closest witnesses to this overhead/waste.

I think using/not using agile is like doing business with a contract vs a handshake. When there are few enough people who trust each other, you can get by on a handshake. When you get into larger dollar amounts (like paying an office full of developers), sometimes its better to use a contract so you have some perception and promises about where your money is going.

Now, agile is of course not a contract, but if teams meet their deliverables, the business can at least see where their money went, which they are entitled to do.