11 ms·

> Supervisory managers brandishing Agile + endless meetings Personally for me - this led to burnout and I have quit last two jobs that used Agile faster than I

> Supervisory managers brandishing Agile + endless meetings Personally for me - this led to burnout and I have quit last two jobs that used Agile faster than I have the 2 before that didn't use Agile. Agile is very clearly being misused to turn developers into factory line workers whose productivity can be measured by number of commits, reviews and docs they put out every two weeks. And the meetings it takes to do Sprint planning, stand-ups, reviews, demos, retros are really killing any possibility of developers having a flow of uninterrupted time to do what they need to. And the burnout article linked in the OP makes a great point about inputs to development teams not being measured. At some places developers are left to spec out stories and others have Architects / Tech Leads do it - in either case that in itself is a large chunk of work that takes up huge amount of time that no one is rewarded for in any way! Mostly though keeping the churn going is what gets really tiring - do most orgs have work that a) needs to be done every two weeks and b) can be done in two weeks perpetually? The pressure leads to manufacturing bite sized requirements that can be demoed in two weeks - the real impact of that work is almost always never evaluated. Combine this pressure with time crunch that prevents people from spending quality time together to ponder bigger, high impact problems and collaborate on solving those within the meeting heavy Agile process and you are never going to get anything meaningful done. This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution. The trouble is software / IT is not at all like rolling cars out on a factory line so it all falls apart. Edit: By Agile I meant Scrum really.

DougBTX 5y ago
> This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution. Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden.
- blackp1nk 5y ago
  Agree to this. Daily standups are the bane of many people's existence.
  - vorticalbox 5y ago
    wasting time hearing about peoples work yesterday/today that I am not involved with nor has any impact on my work is a waste of every ones time.
    - jseban 5y ago
      Yeah, and that feeling of someone oversharing something both irrelevant and boring, while you already have an overfull short term memory from your own work, AND being forced to pretend to pay attention, it's just so painful.
  - rypskar 5y ago
    I'm in a distributed team where the daily standups are optional. Almost everyone join every day and say it is good to see the others at least for a short while every day
    - odshoifsdhfs 5y ago
      I'm going to be that guy: They say it is good to see others or they say what is expected of them? Is like the conversation yesterday about leaving interviews. You don't say Person was is shit and an asshole but you say a better opportunity came up. Heck, even during job interviews, you don't answer 'why work here' with 'money' but 'looking for a new challenge, or interesting work or whatnot'
      - diatone 5y ago
        As someone who enjoys sharing a similar sense of humour and outlook as the people I work with, I'm personally more than happy to spend 15 minutes goofing around before a day of knuckling down and getting shit done. YMMV
RNCTX 5y ago
Which is to say, a competent manager of developers doesn't need someone to hand him a textbook that denotes how to organize a development project, and people who do replace their own void in competence with meetings and reports?
- hef19898 5y ago
  If you witnessed the transition from mediocre, not to speak of incompetent, manager to a competent one, your comment doesn't need an more explanation.
pydry 5y ago
Agile is A) vague and inspiring enough that everybody can project their desires, hopes and dreams on it and B) vague enough that it can be twisted by any authority to serve pretty much any purpose they like. This is intrinsic to the entire movement and was from the very beginning as far as I can see. There were some good ideas that emerged from the auspices of the movement but the movement itself never really committed itself too hard to any of them.
- hurflmurfl 5y ago
  My opinion is that Agile is intended to be vague, as there can't be a silver bullet plan that fits every occasion. Of course, "no silver bullet" sells way worse than "I've got a silver bullet for you right here, Mr. CEO, just sign here". Let's check some "principles" posted at https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. To me it looks like all of the above is screaming at you "quit your great perfect plan and look at the real world instead". If something's wrong, adapt and adjust - this is what agility is about. You can't calcify agility. P.S. not really in any particular argument with you, just that your comment prompted me to write some thoughts that have coagulated in my mind while going through the comments here.
- oblio 5y ago
  Wasn't the original manifesto written by consultants?
  - jk20 5y ago
    Agile may have started with good intentions,but was repurposed by nontechnical managers looking for a chunk of money which really belongs to the developers. Agile theory and practice does not address any concrete technical issues, but it is a hand-waving about meetings, demos, hierarchy, convoluted bureaucracy related to the tickets (cf. the Law of Triviality). I do hope that the advent of remote work and networking as opposed to corporatocracy will wipe the Agile grifters out of existence.
polskibus 5y ago
What do you mean by not using agile? No time boxing? Continuous delivery? 1yr waterfall?
- jokethrowaway 5y ago
  He's not complaining about Agile itself. He's complaining of the non-Agile practices that became synonymous with Agile, eg. Scrum, thanks to Agile coaches that feared losing power.
  - polskibus 5y ago
    He must've used some kind of work planning and scheduling though, even if it was 'as soon as possible but not sooner'
- blinkingled 5y ago
  I have worked on a combination of Time boxed and CD. The timeboxed ones had a overarching timeframe defined but we had lot of leeway within that to go and do our thing - sometimes we would spend more time thinking about how to solve it more efficiently - do PoCs, brainstorms and that saved us implementation time. We would have weekly status update meetings and more if needed - it was mostly self organizing and so long as we had people that cared and knew what they were doing it really worked well. The CD ones were ones that actually needed continuous work - lots of new code needing routine bug fixes, Security fixes, artifact updates, incremental devops/automation for legacy projects etc.
benttoothpaste 5y ago
In my case it was gitprime. This is a software to stack rank based on git commits. Since good developers supposedly make lots of small commits, if someone makes too few, they are bad. Also bug fixes are penalized as “code churn”.
- IggleSniggle 5y ago
  This is downright hilarious. First order of business is to write a program that generates a commit + well-form commit message whenever a character is typed. “Ah, benttoothpaste, I see you made 70000 commits last week! Fantastic progress, we’re very proud to have you on the team! Can you tell us a little bit about how you achieved this incredible breakthrough performance? Your bonus check is already in the mail”
tmountain 5y ago
Spot on and well said!
jokethrowaway 5y ago
Completely agree and I left my last job for exactly this reason. Endless meetings fuelled by direction coming from above of needing to cooperate more and Agile coaches popping up. The CTO and some early developers in the company were basically meeting in secret, deciding what new cool thing they had to run in teams (whether mob programming for hours or some new way of organising the backlog) and then all the early developers (who didn't have a formal manager title - sure, just normal developers like everyone else! Flat structure! Everyone has power!) were going back to the teams and proposing this new cool thing. The majority didn't have the heart to put them down and soon the trial would become a standard practice. This is not Agile, this goes against the Agile philosophy of putting people first in front of process. Agile doesn't need coaches, just make your staff read the manifesto. If you have an Agile coach scheduling meetings nobody cares about, you're putting process in front of people. From my experience, people are generally nice (not including myself in this group) and they won't say to your face that your job is useless. Heck, they'll even praise how good of a coach you are and ask for more meetings - while complaining in private about long meetings and leaving in record numbers.
hsuduebc2 5y ago
I would love to work without these idiotic ceremonies. I get into fight with our agile coach because he insisted on making new features instead of fixing bugs because we didn't have anything new to present in demos. Stupid.
- oblio 5y ago
  It's not stupid. If you have normal stakeholders, they want to see features. You, as a developer or maybe an existing user, want to fix bugs. But new features bring new customers. Too many demos without new features and the engineering political capital will plummet like a rock. That's when things get dicey and people get moved around or fired.
  - jk20 5y ago
    Functionality is itself a feature. Stakeholders are sometimes just a bunch of managers waiting for you to finish work to take credit for it.
  - Clubber 5y ago
    Apple's Snow Leopard was mainly an under-the-hood redesign and re-architecture with very few features. It's considered by many to be one of if not the best OS they've ever released. So I understand your point and it's valid, but it's stakeholders are really a force to be managed properly, not capitulated to. The capitulation, I suspect, comes from the imposter syndrome many managers have, who are just happy to be in that position. They haven't yet grown the spine to do what's best for the project. I don't care how many features an OS has (Windows 8). If it's buggy and unusable, it will be perceived as a bomb.
  - hsuduebc2 5y ago
    I should give some context. We're developing an internal application for the staff at the branch. A customer comes into the branch and a company employee sets it up in the app. We have a release every two months and the demo is every two weeks. The problem is that not many people come to the demo because they are not interested. Our agile coach says it's because we're not delivering enough new features and we should be doing more. For us, it's not the app that sells, it's the people. An app is a tool to get somewhere, store data, but it has a lot of bugs in it. I'd rather have a functional product than useless metrics that in our case doesn't increase sales. That seems silly to me.
praptak 5y ago
"This is not to say Agile itself is bad" But it is bad, no-good, horrible and sucky. If you do have the skill and diligence which are necessary to implement it (in a way that doesn't horribly suck), then you don't need to formally implement Agile. The most productive teams I worked in invariably converged on something like this: some kind of a backlog + a way to know who is working on what + informal but frequent and active communication I think that if you look at the formal and semi-formal methods it's Kanban that is the closest to this model. If you need to placate people who insist on using "A Method", then at least try to convince them to use Kanban.
- blinkingled 5y ago
  I completely agree - that's really what I meant by Agile as a philosophy isn't bad - its implementations? Sure. You hire competent developers that want to do cool things and you give them the basic necessary tools to self organize. You give them sound direction and a reasonable timeframe and they will self organize - maybe have infrequent checkups to ensure nothing is derailing or needs escalation and most projects can be successful with minimum overheads.
  - lostcolony 5y ago
    I describe this as "agile manifesto" vs "agile methodology". The agile manifesto attempted to describe a culture where devs could get things done. All the methodologies are a bundle of useful ideas that came out of people attempting to find a process that fit the agile manifesto (and still delivered what the business cared about), but have been taken by consultancies, stripped of context, and sold as a panacea for what ails a company. It's attempting to treat the symptoms, not the cause; the cause of what ails a company is bad culture, not bad process.
- dennis_jeeves 5y ago
  Thanks for using the terms 'formal' and 'informal'. Smart people/groups always refine their process so that it works optimally. I'm sure that long before this Agile nonsense there were team that implemented aspects of it informally. Something similar goes for what is considered the 'scientific' method. It probably existed in various forms before the term was coined. Notice how the word 'science' is used ( or misused if you will) and the 'scientific' method used to justify a claim. Teaching low IQ people a 'process' that involves refining it later, never really works.
nanis 5y ago
> And the meetings it takes to do Sprint planning, stand-ups, reviews, demos, retros are really killing any possibility of developers having a flow of uninterrupted time to do what they need to. This is because the Scrum "masters" are not masters of the domain. In most cases, they went to a two-week class to get "certified". They have no understanding of the development process and they are not accountable to developers at all, only to upper management to whom they sell the word "agile" as a project management approach. What they are doing with all the planning/prep all the time, of course, is playing mini-waterfall in 3-6 month horizons. > the real impact of that work is almost always never evaluated. Because that might actually lead to reflecting on the performance of mid-managers and the scrum "masters". These groups tend to view developers as assembly line workers, they still think the "size" of a PR is indicative of its importance (think the KLOC counters of yore), and they think "key person risk" can be mitigated by eliminating said key person instead of fostering an environment that open to knowledge/experience sharing. Those who can't do the tech get threatened by those who can and instead of focusing on their own comparative advantage and ensuring a productive environment, they focus on subjugating those who can do the tech to their every wish (fixating on things like label colors, prefixing every ticket with TAT, insisting that every ticket must be comprehensible to any random person in the company etc). When 30 hours in a week are taken up by mandatory meetings, they then penalize people for not spending 40 hours on development. I've seen places which required keeping timesheets with 15 minute resolution. I know there are places that are not like this, but I also know enough places that are.
- NortySpock 5y ago
  We're on the 15 minute schedule since some of my team's work is billable hours. At this point I've automated most of the time tracking into Excel. (CTRL-SHIFT-semicolon injects the current time into the current cell) Timecard still takes an hour of work a week because I have to fill out both Jira time and HR time separately, because they want it at different granularities... Ah well.
sprafa 5y ago
The Toyota process says - you cannot manage a production line effectively if you don’t understand it. Agile has become a way for people with no development experience to “manage” developers and that will always be wrong. The West’s obsession with “managerial” experience being a thing you can learn start to manage “anything” from is the origin of much of our malcontent. Management is just something you add on top of knowing how things work. It’s not valuable as an isolated skill.
- blinkingled 5y ago
  > Agile has become a way for people with no development experience to “manage” developers and that will always be wrong True of course but also now the Developers and Architects are compensating for the scrum master's/manager's lack of knowledge in tangible and intangible ways - they bear the brunt of everything and that can become the many straws that broke the camel's back thing easily.
  - oytis 5y ago
    > True of course but also now the Developers and Architects are compensating for the scrum master's/manager's lack of knowledge What do you mean? Scrum master's role is nothing more than facilitating the process, they don't need any technical knowledge at all.
    - blinkingled 5y ago
      In reality they turn into work assigners - individual A in team C has no stories to groom - let's give them some stories from Epic D which has more story points per developer. Think about how simplistic that sounds to the scrum master and how complicated it is in practice and who is filling in the gaps.
      - imbnwa 5y ago
        The sheer arrogance I've seen a SCRUM Master speak with on matters like these with zero development experience sent me up the wall.
matt_s 5y ago
Small "a" agile is perfectly fine. I worked in an organization that did "Scrum of Scrums" (aka waterfall disguised as Scrum) and my job description could have easily been "attends meetings". Kanban paired with CI/CD is the best workflow, in my opinion. Break work down into known chunks, no estimation games, work it through a kanban board and put it in production when its done. A known side effect of doing this process is you may have people work on things that get de-prioritized and they sit there for a while and/or turn into waste. I'd rather have that known side effect than side effects like burnout, endless meetings and death march waterfall projects. Devs can still learn and hone their skills developing things that may end up as waste. Devs get nothing out of endless meetings and trying to meet arbitrary metrics.
ryandvm 5y ago
Agile is like Communism. Sounds good in theory, but it's never actually been used successfully. And every time someone tells a story about it failing the apologists inevitably reply with, "but that wasn't real agile." I would suggest that if something is so hard to get right, then maybe it's not such a great methodology after all.
- pyrale 5y ago
  > I would suggest that if something is so hard to get right, then maybe it's not such a great methodology after all. Here is the thing, though: Agile is not a methodology. That's why, whenever people get sold a methodology and complain about it, they get the answer: > "but that wasn't real agile." As for why it's so common for people to buy "agile" from consultancies and end up with bad results, I would argue that "agile transformation" is a market for lemons [1]. It has been so for a decade now. For the interested people, I would suggest to learn about it by yourself from non-commercial sources, and to learn what you're talking about before contracting consultants. [1]: https://en.wikipedia.org/wiki/The_Market_for_Lemons https://en.wikipedia.org/wiki/The_Market_for_Lemons
- conradfr 5y ago
  I think Scrum has sometimes its place for web agencies or the like, with external clients with deadlines and budgets. The mistake was applying it elsewhere.
  - blacktriangle 5y ago
    Yeah that was a huge transition to make when working for an agency. Realizing that the bullshit work to communicate with the client while technically slowing the whole project down was the most important task you had. Reason being, the "product" wasn't really the code you were developing for the client, it was delivering client happiness, and often they cared more about being in the loop than getting the maximal amount of functionality.
  - jseban 5y ago
    Yeah this is how I always felt about Scrum, that it's made for IT consulting firms to manage the relationship with the client, and that the "product owner" is in the clients organisation, and scrum master works in the consulting firm, so it's a tool to negotiate and manage expectations for delivery.
zelos 5y ago
> The pressure leads to manufacturing bite sized requirements that can be demoed in two weeks... Yes, the whole 2 week 'sprint' thing really wears me down. I can see the value of deadlines and splitting work up, but between all the release/demo/planning overhead and the constant rush to fit things in it leaves me with a constant low-level anxiety. 3 weeks seems like a more reasonable figure to me. Or with a senior team, just having a prioritised backlog of tasks and doing them in order (sounds crazy, I know).
- coffeefirst 5y ago
  I've come to see a lot of these tools as sharp objects. Used well, sprints can help figure out how to put tracks of work in parallel, and keep anyone from overloading themselves. Used badly, they're perpetual deadlines that fault individuals for inefficiencies in planning and create all kinds of fun toxic incentives. To add insult to injury, everyone that complains about agile just gets told they're "doing it wrong," which 1. no shit, that's the substance of that complaint, and 2. blames individuals for what's essentially a management failure.
snarf21 5y ago
One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.
jseban 5y ago
Yeah same here, I quit my last job when they started the transformation to Scrum and I got a supervisory manager. Not only does it turn developers into factory workers, but also which is my biggest source of burnout, it turns developers into some kind of dysfunctional and immature people who need help with every kind of basic communication and decision, and forces you to undergo a quasi pop psychology group therapy. That's where I get the most burnout, I'm a grown-up and a normal well rounded person. I'm healthy, I can communicate, I can work in teams. Why do I not even get the benefit of the doubt that I can function normally in a team and do my job, and immediately get thrown into this awkward depressing self-help group therapy bs.
lumost 5y ago
TBH every team/company I've seen that uses strict agile/scrum is surpassed by the non-agile teams eventually. There are exceptions to this for teams that have modified agile/scrum to the point they can sensibly do long-term project planning and account for short-term hickups. Scrum works if the manager is unclear on what the team does and when. Sometimes software teams are low productivity because people straight up aren't working, sometimes it's because there are a hundred operational tasks eating up all the bandwidth, and sometimes the team members aren't prioritizing the right work. In such a world scrum gives day to day status of the work everyone is doing and they can provide feedback to the team to get the team moving faster. It's a short-term fix that sometimes gets pushed as a panacea for all software team management problems.
Tarucho 5y ago
Is Scrum the problem? Or is that tech, which has become high status in the last 6/7 years is starting to attract the kind people that went to make a management career into more prestigious areas and they are starting to manage us in the same way they manage these other areas? 20 years ago, friends which worked in non-management positions in hr, accounting, finance, etc envied the freedom I had being low-level worker. Nowadays I just follow orders and work on tickets as they do.
JKCalhoun 5y ago
> Supervisory managers brandishing Agile + endless meetings Yes, that is the line that resonated with me as well. Twenty-five years now as a "corporate programmer" and I have watched the job go from cowboy-coder to "i"-dotter-"t" crosser. There is way too much process now and it's not fun. Perhaps it's a sign of the industry maturing, the stakes are higher. Perhaps it's a sign that management no longer trust their devs. Perhaps one follows the other. Regardless, I am soon to be exiting corporate and the new way is not something I will miss.
jseban 5y ago
I wish scrum had some support for decision making, where you'd attempt to evaluate suggested solutions based on the actual goals of the team/company, have healthy moderated debates, and in the end (by voting or manager) make a decision which is then documented, with a note on when it can be revisited the earliest. Scrum just pretends that there are no decisions to be made, or if there is, that they are obviously simple and that everyone spontaneously just get along. In reality there are a lot of pretty damn important decisions to be made in developing and evolving software, and people have widely different ideas, and smart people are usually very stubborn as well. I had a guy insist that a build script for a React app should absolutely be written in Ant. And nothing else. I argued with him that it's highly unusual, and that shell script or Makefile would be a better choice, pleaded with the rest of the team etc. It was massively exhausting for me and the whole team, this went on almost a whole week, and when I finally got my way on this issue, he just rage quit the team and transferred to another. I just wish there was a manager who would be "the bad guy" and make decisions like this like the old fashioned way, it's not without benefits. And similar incidents happen to me all the time, whenever I use SQL to solve something, use the command line, or when I simplify some code, I always get attacked by (mostly) juniors. I just don't understand how to contribute as a senior when you have no decision power and no impact, and every decision is made in an undefined way (in reality by exhausting arguing).
Viliam1234 5y ago
> This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution. > Edit: By Agile I meant Scrum really. The same thing would happen with any form of Agile, if it became widespread enough. In most companies that use Scrum, managers change at least half of the rules of Scrum. In a parallel reality, you would see them change half of the rules of Kanban or Extreme Programming or whatever... and then developers would complain that (the actually practiced) Kanban or XP or whatever is not true Agile but more like the opposite of it. The problem is that managers exist and want to keep their jobs. (Even worse, the power of a manager depends on how many managers are in the hierarchy below him or her, so even managers in the higher positions, who could in theory make the company more agile by firing the managers below them while keeping their own jobs, do not have an incentive to do so.) So whenever someone proposes Agile, managers modify it into Agile+micromanagement, to justify their jobs. If you want to have actual Agile, you need to start without managers. If you have a hierarchy of managers who decide to implement Agile, you have already lost.
jjav 5y ago
> Personally for me - this led to burnout and I have quit last two jobs that used Agile faster than I have the 2 before that didn't use Agile. So much this. The continuous mental stress that agile imposes is so harmful. Having to re-justify your job every morning in daily status meetings, then having to spend all day worrying about having enough to say tomorrow. Counterproductively, it prevents me from getting in the zone and getting more done, so now I have less to status report tomorrow. Apparently it's not just me either. I know someone who is a mental health professional (Silicon Valley area) and they've mentioned seeing an increasing trend of patients who bring up agile at the workplace as a cause for the stress that leads them to go see a mental health professional.
dennis_jeeves 5y ago
The Agile/Scrum emperor has no clothes.
misterflibble 5y ago
I agree completely with everything in your comment. I work at a company where "Agile evangelists" are charged with making technical decisions and prioritising work over actual software developers. If I go job hunting again, I want to avoid that sort of company. How do I do detect that sort of culture before I join the company?

DougBTX 5y ago

blackp1nk 5y ago
Agree to this. Daily standups are the bane of many people's existence.
- vorticalbox 5y ago
  wasting time hearing about peoples work yesterday/today that I am not involved with nor has any impact on my work is a waste of every ones time.
  - jseban 5y ago
    Yeah, and that feeling of someone oversharing something both irrelevant and boring, while you already have an overfull short term memory from your own work, AND being forced to pretend to pay attention, it's just so painful.
- rypskar 5y ago
  I'm in a distributed team where the daily standups are optional. Almost everyone join every day and say it is good to see the others at least for a short while every day
  - odshoifsdhfs 5y ago
    I'm going to be that guy: They say it is good to see others or they say what is expected of them? Is like the conversation yesterday about leaving interviews. You don't say Person was is shit and an asshole but you say a better opportunity came up. Heck, even during job interviews, you don't answer 'why work here' with 'money' but 'looking for a new challenge, or interesting work or whatnot'
    - diatone 5y ago
      As someone who enjoys sharing a similar sense of humour and outlook as the people I work with, I'm personally more than happy to spend 15 minutes goofing around before a day of knuckling down and getting shit done. YMMV

RNCTX 5y ago

Which is to say, a competent manager of developers doesn't need someone to hand him a textbook that denotes how to organize a development project, and people who do replace their own void in competence with meetings and reports?

hef19898 5y ago
If you witnessed the transition from mediocre, not to speak of incompetent, manager to a competent one, your comment doesn't need an more explanation.

pydry 5y ago

Agile is A) vague and inspiring enough that everybody can project their desires, hopes and dreams on it and B) vague enough that it can be twisted by any authority to serve pretty much any purpose they like. This is intrinsic to the entire movement and was from the very beginning as far as I can see. There were some good ideas that emerged from the auspices of the movement but the movement itself never really committed itself too hard to any of them.

hurflmurfl 5y ago
My opinion is that Agile is intended to be vague, as there can't be a silver bullet plan that fits every occasion. Of course, "no silver bullet" sells way worse than "I've got a silver bullet for you right here, Mr. CEO, just sign here". Let's check some "principles" posted at https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. To me it looks like all of the above is screaming at you "quit your great perfect plan and look at the real world instead". If something's wrong, adapt and adjust - this is what agility is about. You can't calcify agility. P.S. not really in any particular argument with you, just that your comment prompted me to write some thoughts that have coagulated in my mind while going through the comments here.
oblio 5y ago
Wasn't the original manifesto written by consultants?
- jk20 5y ago
  Agile may have started with good intentions,but was repurposed by nontechnical managers looking for a chunk of money which really belongs to the developers. Agile theory and practice does not address any concrete technical issues, but it is a hand-waving about meetings, demos, hierarchy, convoluted bureaucracy related to the tickets (cf. the Law of Triviality). I do hope that the advent of remote work and networking as opposed to corporatocracy will wipe the Agile grifters out of existence.

polskibus 5y ago

What do you mean by not using agile? No time boxing? Continuous delivery? 1yr waterfall?

jokethrowaway 5y ago
He's not complaining about Agile itself. He's complaining of the non-Agile practices that became synonymous with Agile, eg. Scrum, thanks to Agile coaches that feared losing power.
- polskibus 5y ago
  He must've used some kind of work planning and scheduling though, even if it was 'as soon as possible but not sooner'
blinkingled 5y ago
I have worked on a combination of Time boxed and CD. The timeboxed ones had a overarching timeframe defined but we had lot of leeway within that to go and do our thing - sometimes we would spend more time thinking about how to solve it more efficiently - do PoCs, brainstorms and that saved us implementation time. We would have weekly status update meetings and more if needed - it was mostly self organizing and so long as we had people that cared and knew what they were doing it really worked well. The CD ones were ones that actually needed continuous work - lots of new code needing routine bug fixes, Security fixes, artifact updates, incremental devops/automation for legacy projects etc.

benttoothpaste 5y ago

In my case it was gitprime. This is a software to stack rank based on git commits. Since good developers supposedly make lots of small commits, if someone makes too few, they are bad. Also bug fixes are penalized as “code churn”.

IggleSniggle 5y ago
This is downright hilarious. First order of business is to write a program that generates a commit + well-form commit message whenever a character is typed. “Ah, benttoothpaste, I see you made 70000 commits last week! Fantastic progress, we’re very proud to have you on the team! Can you tell us a little bit about how you achieved this incredible breakthrough performance? Your bonus check is already in the mail”

tmountain 5y ago

Spot on and well said!

jokethrowaway 5y ago

Completely agree and I left my last job for exactly this reason. Endless meetings fuelled by direction coming from above of needing to cooperate more and Agile coaches popping up. The CTO and some early developers in the company were basically meeting in secret, deciding what new cool thing they had to run in teams (whether mob programming for hours or some new way of organising the backlog) and then all the early developers (who didn't have a formal manager title - sure, just normal developers like everyone else! Flat structure! Everyone has power!) were going back to the teams and proposing this new cool thing. The majority didn't have the heart to put them down and soon the trial would become a standard practice. This is not Agile, this goes against the Agile philosophy of putting people first in front of process. Agile doesn't need coaches, just make your staff read the manifesto. If you have an Agile coach scheduling meetings nobody cares about, you're putting process in front of people. From my experience, people are generally nice (not including myself in this group) and they won't say to your face that your job is useless. Heck, they'll even praise how good of a coach you are and ask for more meetings - while complaining in private about long meetings and leaving in record numbers.

hsuduebc2 5y ago

I would love to work without these idiotic ceremonies. I get into fight with our agile coach because he insisted on making new features instead of fixing bugs because we didn't have anything new to present in demos. Stupid.

oblio 5y ago
It's not stupid. If you have normal stakeholders, they want to see features. You, as a developer or maybe an existing user, want to fix bugs. But new features bring new customers. Too many demos without new features and the engineering political capital will plummet like a rock. That's when things get dicey and people get moved around or fired.
- jk20 5y ago
  Functionality is itself a feature. Stakeholders are sometimes just a bunch of managers waiting for you to finish work to take credit for it.
- Clubber 5y ago
  Apple's Snow Leopard was mainly an under-the-hood redesign and re-architecture with very few features. It's considered by many to be one of if not the best OS they've ever released. So I understand your point and it's valid, but it's stakeholders are really a force to be managed properly, not capitulated to. The capitulation, I suspect, comes from the imposter syndrome many managers have, who are just happy to be in that position. They haven't yet grown the spine to do what's best for the project. I don't care how many features an OS has (Windows 8). If it's buggy and unusable, it will be perceived as a bomb.
- hsuduebc2 5y ago
  I should give some context. We're developing an internal application for the staff at the branch. A customer comes into the branch and a company employee sets it up in the app. We have a release every two months and the demo is every two weeks. The problem is that not many people come to the demo because they are not interested. Our agile coach says it's because we're not delivering enough new features and we should be doing more. For us, it's not the app that sells, it's the people. An app is a tool to get somewhere, store data, but it has a lot of bugs in it. I'd rather have a functional product than useless metrics that in our case doesn't increase sales. That seems silly to me.

praptak 5y ago

"This is not to say Agile itself is bad" But it is bad, no-good, horrible and sucky. If you do have the skill and diligence which are necessary to implement it (in a way that doesn't horribly suck), then you don't need to formally implement Agile. The most productive teams I worked in invariably converged on something like this: some kind of a backlog + a way to know who is working on what + informal but frequent and active communication I think that if you look at the formal and semi-formal methods it's Kanban that is the closest to this model. If you need to placate people who insist on using "A Method", then at least try to convince them to use Kanban.

blinkingled 5y ago
I completely agree - that's really what I meant by Agile as a philosophy isn't bad - its implementations? Sure. You hire competent developers that want to do cool things and you give them the basic necessary tools to self organize. You give them sound direction and a reasonable timeframe and they will self organize - maybe have infrequent checkups to ensure nothing is derailing or needs escalation and most projects can be successful with minimum overheads.
- lostcolony 5y ago
  I describe this as "agile manifesto" vs "agile methodology". The agile manifesto attempted to describe a culture where devs could get things done. All the methodologies are a bundle of useful ideas that came out of people attempting to find a process that fit the agile manifesto (and still delivered what the business cared about), but have been taken by consultancies, stripped of context, and sold as a panacea for what ails a company. It's attempting to treat the symptoms, not the cause; the cause of what ails a company is bad culture, not bad process.
dennis_jeeves 5y ago
Thanks for using the terms 'formal' and 'informal'. Smart people/groups always refine their process so that it works optimally. I'm sure that long before this Agile nonsense there were team that implemented aspects of it informally. Something similar goes for what is considered the 'scientific' method. It probably existed in various forms before the term was coined. Notice how the word 'science' is used ( or misused if you will) and the 'scientific' method used to justify a claim. Teaching low IQ people a 'process' that involves refining it later, never really works.

nanis 5y ago

> And the meetings it takes to do Sprint planning, stand-ups, reviews, demos, retros are really killing any possibility of developers having a flow of uninterrupted time to do what they need to. This is because the Scrum "masters" are not masters of the domain. In most cases, they went to a two-week class to get "certified". They have no understanding of the development process and they are not accountable to developers at all, only to upper management to whom they sell the word "agile" as a project management approach. What they are doing with all the planning/prep all the time, of course, is playing mini-waterfall in 3-6 month horizons. > the real impact of that work is almost always never evaluated. Because that might actually lead to reflecting on the performance of mid-managers and the scrum "masters". These groups tend to view developers as assembly line workers, they still think the "size" of a PR is indicative of its importance (think the KLOC counters of yore), and they think "key person risk" can be mitigated by eliminating said key person instead of fostering an environment that open to knowledge/experience sharing. Those who can't do the tech get threatened by those who can and instead of focusing on their own comparative advantage and ensuring a productive environment, they focus on subjugating those who can do the tech to their every wish (fixating on things like label colors, prefixing every ticket with TAT, insisting that every ticket must be comprehensible to any random person in the company etc). When 30 hours in a week are taken up by mandatory meetings, they then penalize people for not spending 40 hours on development. I've seen places which required keeping timesheets with 15 minute resolution. I know there are places that are not like this, but I also know enough places that are.

NortySpock 5y ago
We're on the 15 minute schedule since some of my team's work is billable hours. At this point I've automated most of the time tracking into Excel. (CTRL-SHIFT-semicolon injects the current time into the current cell) Timecard still takes an hour of work a week because I have to fill out both Jira time and HR time separately, because they want it at different granularities... Ah well.

sprafa 5y ago

The Toyota process says - you cannot manage a production line effectively if you don’t understand it. Agile has become a way for people with no development experience to “manage” developers and that will always be wrong. The West’s obsession with “managerial” experience being a thing you can learn start to manage “anything” from is the origin of much of our malcontent. Management is just something you add on top of knowing how things work. It’s not valuable as an isolated skill.

blinkingled 5y ago
> Agile has become a way for people with no development experience to “manage” developers and that will always be wrong True of course but also now the Developers and Architects are compensating for the scrum master's/manager's lack of knowledge in tangible and intangible ways - they bear the brunt of everything and that can become the many straws that broke the camel's back thing easily.
- oytis 5y ago
  > True of course but also now the Developers and Architects are compensating for the scrum master's/manager's lack of knowledge What do you mean? Scrum master's role is nothing more than facilitating the process, they don't need any technical knowledge at all.
  - blinkingled 5y ago
    In reality they turn into work assigners - individual A in team C has no stories to groom - let's give them some stories from Epic D which has more story points per developer. Think about how simplistic that sounds to the scrum master and how complicated it is in practice and who is filling in the gaps.
    - imbnwa 5y ago
      The sheer arrogance I've seen a SCRUM Master speak with on matters like these with zero development experience sent me up the wall.

matt_s 5y ago

Small "a" agile is perfectly fine. I worked in an organization that did "Scrum of Scrums" (aka waterfall disguised as Scrum) and my job description could have easily been "attends meetings". Kanban paired with CI/CD is the best workflow, in my opinion. Break work down into known chunks, no estimation games, work it through a kanban board and put it in production when its done. A known side effect of doing this process is you may have people work on things that get de-prioritized and they sit there for a while and/or turn into waste. I'd rather have that known side effect than side effects like burnout, endless meetings and death march waterfall projects. Devs can still learn and hone their skills developing things that may end up as waste. Devs get nothing out of endless meetings and trying to meet arbitrary metrics.

ryandvm 5y ago

Agile is like Communism. Sounds good in theory, but it's never actually been used successfully. And every time someone tells a story about it failing the apologists inevitably reply with, "but that wasn't real agile." I would suggest that if something is so hard to get right, then maybe it's not such a great methodology after all.

pyrale 5y ago
> I would suggest that if something is so hard to get right, then maybe it's not such a great methodology after all. Here is the thing, though: Agile is not a methodology. That's why, whenever people get sold a methodology and complain about it, they get the answer: > "but that wasn't real agile." As for why it's so common for people to buy "agile" from consultancies and end up with bad results, I would argue that "agile transformation" is a market for lemons [1]. It has been so for a decade now. For the interested people, I would suggest to learn about it by yourself from non-commercial sources, and to learn what you're talking about before contracting consultants. [1]: https://en.wikipedia.org/wiki/The_Market_for_Lemons https://en.wikipedia.org/wiki/The_Market_for_Lemons
conradfr 5y ago
I think Scrum has sometimes its place for web agencies or the like, with external clients with deadlines and budgets. The mistake was applying it elsewhere.
- blacktriangle 5y ago
  Yeah that was a huge transition to make when working for an agency. Realizing that the bullshit work to communicate with the client while technically slowing the whole project down was the most important task you had. Reason being, the "product" wasn't really the code you were developing for the client, it was delivering client happiness, and often they cared more about being in the loop than getting the maximal amount of functionality.
- jseban 5y ago
  Yeah this is how I always felt about Scrum, that it's made for IT consulting firms to manage the relationship with the client, and that the "product owner" is in the clients organisation, and scrum master works in the consulting firm, so it's a tool to negotiate and manage expectations for delivery.

zelos 5y ago

> The pressure leads to manufacturing bite sized requirements that can be demoed in two weeks... Yes, the whole 2 week 'sprint' thing really wears me down. I can see the value of deadlines and splitting work up, but between all the release/demo/planning overhead and the constant rush to fit things in it leaves me with a constant low-level anxiety. 3 weeks seems like a more reasonable figure to me. Or with a senior team, just having a prioritised backlog of tasks and doing them in order (sounds crazy, I know).

coffeefirst 5y ago
I've come to see a lot of these tools as sharp objects. Used well, sprints can help figure out how to put tracks of work in parallel, and keep anyone from overloading themselves. Used badly, they're perpetual deadlines that fault individuals for inefficiencies in planning and create all kinds of fun toxic incentives. To add insult to injury, everyone that complains about agile just gets told they're "doing it wrong," which 1. no shit, that's the substance of that complaint, and 2. blames individuals for what's essentially a management failure.

snarf21 5y ago

One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.

jseban 5y ago

Yeah same here, I quit my last job when they started the transformation to Scrum and I got a supervisory manager. Not only does it turn developers into factory workers, but also which is my biggest source of burnout, it turns developers into some kind of dysfunctional and immature people who need help with every kind of basic communication and decision, and forces you to undergo a quasi pop psychology group therapy. That's where I get the most burnout, I'm a grown-up and a normal well rounded person. I'm healthy, I can communicate, I can work in teams. Why do I not even get the benefit of the doubt that I can function normally in a team and do my job, and immediately get thrown into this awkward depressing self-help group therapy bs.

lumost 5y ago

TBH every team/company I've seen that uses strict agile/scrum is surpassed by the non-agile teams eventually. There are exceptions to this for teams that have modified agile/scrum to the point they can sensibly do long-term project planning and account for short-term hickups. Scrum works if the manager is unclear on what the team does and when. Sometimes software teams are low productivity because people straight up aren't working, sometimes it's because there are a hundred operational tasks eating up all the bandwidth, and sometimes the team members aren't prioritizing the right work. In such a world scrum gives day to day status of the work everyone is doing and they can provide feedback to the team to get the team moving faster. It's a short-term fix that sometimes gets pushed as a panacea for all software team management problems.

Tarucho 5y ago

Is Scrum the problem? Or is that tech, which has become high status in the last 6/7 years is starting to attract the kind people that went to make a management career into more prestigious areas and they are starting to manage us in the same way they manage these other areas? 20 years ago, friends which worked in non-management positions in hr, accounting, finance, etc envied the freedom I had being low-level worker. Nowadays I just follow orders and work on tickets as they do.

JKCalhoun 5y ago

> Supervisory managers brandishing Agile + endless meetings Yes, that is the line that resonated with me as well. Twenty-five years now as a "corporate programmer" and I have watched the job go from cowboy-coder to "i"-dotter-"t" crosser. There is way too much process now and it's not fun. Perhaps it's a sign of the industry maturing, the stakes are higher. Perhaps it's a sign that management no longer trust their devs. Perhaps one follows the other. Regardless, I am soon to be exiting corporate and the new way is not something I will miss.

jseban 5y ago

I wish scrum had some support for decision making, where you'd attempt to evaluate suggested solutions based on the actual goals of the team/company, have healthy moderated debates, and in the end (by voting or manager) make a decision which is then documented, with a note on when it can be revisited the earliest. Scrum just pretends that there are no decisions to be made, or if there is, that they are obviously simple and that everyone spontaneously just get along. In reality there are a lot of pretty damn important decisions to be made in developing and evolving software, and people have widely different ideas, and smart people are usually very stubborn as well. I had a guy insist that a build script for a React app should absolutely be written in Ant. And nothing else. I argued with him that it's highly unusual, and that shell script or Makefile would be a better choice, pleaded with the rest of the team etc. It was massively exhausting for me and the whole team, this went on almost a whole week, and when I finally got my way on this issue, he just rage quit the team and transferred to another. I just wish there was a manager who would be "the bad guy" and make decisions like this like the old fashioned way, it's not without benefits. And similar incidents happen to me all the time, whenever I use SQL to solve something, use the command line, or when I simplify some code, I always get attacked by (mostly) juniors. I just don't understand how to contribute as a senior when you have no decision power and no impact, and every decision is made in an undefined way (in reality by exhausting arguing).

Viliam1234 5y ago

> This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution. > Edit: By Agile I meant Scrum really. The same thing would happen with any form of Agile, if it became widespread enough. In most companies that use Scrum, managers change at least half of the rules of Scrum. In a parallel reality, you would see them change half of the rules of Kanban or Extreme Programming or whatever... and then developers would complain that (the actually practiced) Kanban or XP or whatever is not true Agile but more like the opposite of it. The problem is that managers exist and want to keep their jobs. (Even worse, the power of a manager depends on how many managers are in the hierarchy below him or her, so even managers in the higher positions, who could in theory make the company more agile by firing the managers below them while keeping their own jobs, do not have an incentive to do so.) So whenever someone proposes Agile, managers modify it into Agile+micromanagement, to justify their jobs. If you want to have actual Agile, you need to start without managers. If you have a hierarchy of managers who decide to implement Agile, you have already lost.

jjav 5y ago

> Personally for me - this led to burnout and I have quit last two jobs that used Agile faster than I have the 2 before that didn't use Agile. So much this. The continuous mental stress that agile imposes is so harmful. Having to re-justify your job every morning in daily status meetings, then having to spend all day worrying about having enough to say tomorrow. Counterproductively, it prevents me from getting in the zone and getting more done, so now I have less to status report tomorrow. Apparently it's not just me either. I know someone who is a mental health professional (Silicon Valley area) and they've mentioned seeing an increasing trend of patients who bring up agile at the workplace as a cause for the stress that leads them to go see a mental health professional.

dennis_jeeves 5y ago

The Agile/Scrum emperor has no clothes.

misterflibble 5y ago

I agree completely with everything in your comment. I work at a company where "Agile evangelists" are charged with making technical decisions and prioritising work over actual software developers. If I go job hunting again, I want to avoid that sort of company. How do I do detect that sort of culture before I join the company?