8 ms·

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 Lat

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.

jameshart 5y ago
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.
- deleted 5y ago
  [deleted]
- ericbarrett 5y ago
  Unfortunately it’s become a high-confidence signal that shenanigans will be ongoing.
  - Frost1x 5y ago
    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.
    - jameshart 5y ago
      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?
      - junon 5y ago
        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.
        ex_amazon_sde 5y ago
        Spot on. Often it feels like a cult, but even more often is used as a micromanagement tool.
        tharkun__ 5y ago
        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?
        Davertron 5y ago
        > 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.
lmm 5y ago
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.
- ericbarrett 5y ago
  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.
  - jameshart 5y ago
    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.

jameshart 5y ago

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.

deleted 5y ago
[deleted]
ericbarrett 5y ago
Unfortunately it’s become a high-confidence signal that shenanigans will be ongoing.
- Frost1x 5y ago
  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.
  - jameshart 5y ago
    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?
    - junon 5y ago
      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.
      - ex_amazon_sde 5y ago
        Spot on. Often it feels like a cult, but even more often is used as a micromanagement tool.
        tharkun__ 5y ago
        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?
        Davertron 5y ago
        > 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.

lmm 5y ago

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.

ericbarrett 5y ago
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.
- jameshart 5y ago
  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.