6 ms·

Do devs really hate agile? I’ve really enjoyed it in workplaces despite it not always being perfect. I’ve never felt micro managed either, just regularly manage

by kylnew 8y ago

Do devs really hate agile? I’ve really enjoyed it in workplaces despite it not always being perfect. I’ve never felt micro managed either, just regularly managed. I understand that maybe some want more free will to pursue problems the way they feel is right, but it’s a job at the end of the day and you are a human resource being paid to deliver results. Make sure you’re being compensated enough, at least to not feel like you’re being exploited.

v1000a 8y ago
I'm not a human resource, thanks. Yes, competent devs hate agile, incompetent talkers love it because it hides their deficiencies and they can shine in the useless meetings.
- matthewmacleod 8y ago
  That’s a gross oversimplification. I’m a competent, experienced developer. I’be worked in agile, waterfall and “faux-agile” teams. The agile ones have been the best - they adapt quickly to change, have good estimates of progress, and keep all of the team members and wider stakeholders involved in the project. If there are useless meetings in your development team, remove them. If you can’t remove them, then your team is being mismanaged and no form of development methodology will fix that. And also, bear in mind that even among developers on a team there are different sets of skills and preferred working patterns. You may not need some interactions, while other team members benefit from them; remember that the useful measure is the amount of work the team as a whole can achieve!
- cc81 8y ago
  My experience is that it is more likely that "hero devs" who love to do what they think is important rather than what the team needs will hate any attempt to reign them in.
mathieuh 8y ago
I hate it. Constantly being pressured to move some stupid card or add some stupid tag so people’s graphs look nice. I just want to get work done, Scrum just adds overhead.
- cc81 8y ago
  How much overhead is it really? 15 minutes a day at most?
  - pjmlp 8y ago
    Not if you have the misfortune to be a single developer project or having a lead role on a team. Someone needs to convert those Jira/Trello/Wall/... items into nice Excel sheets because upper management won't look at anything else. While you are at it including some nice Powerpoints for the weekly/monthly updates. And on the remaining time do those development tasks, while coaching junior devs at the same time.
    - mdorazio 8y ago
      If you have a lead role on a team the large majority of your time should be leading the team by doing all those non-development tasks. If you're trying to also cram in mission critical development you're trying to do too much or your company's leadership sucks. If it's a single developer project, 1) Agile might not be the best approach, and 2) updates to management should take very little time since you just need to sum up what you personally have accomplished and are planning to accomplish vs. whatever deadlines exist.
      - pjmlp 8y ago
        That's the nice theory and then there are the actual real life projects, hence why we reached the point discussed on the linked article.
        mdorazio 8y ago
        Yes, that is the nice theory and also the nice real world. And yes, I've been on and managed dozens of projects at 10+ companies over the last decade so I feel confident saying that. Sounds to me like your company's leadership just sucks. That's not a problem with the methodology.
- 8y ago
dudul 8y ago
The part I really hate about Agile is how it almost encourages "sloppiness" in requirements (execution too sometimes, but requirements is the part that really drives me crazy). You need to always be "sprinting". There is no time to take a step back and think deeply about the product you are trying to build. No time to think through what a new feature means for your customer and for your existing system. How often do you work on tickets that are completely ironed out? All the actors of the feature are described, all the interactions with their outcomes, all the things to test for, all the new metrics to add to the system? And don't hear me wrong. It's probably the right MO for small companies/products. But once you've reached a certain size for the company, the system and the user base, it's not gonna work. People often laugh at how long it takes for Twitter to introduce a minuscule change in their product, but seriously, I wish a lot of "agile" companies would apply this extreme instead of the completely opposite side of the spectrum: "just start coding this shit, and we'll figure it out later".
randomdata 8y ago
Absolutely. We adopted 'Agile' a little over a year ago and the perverse incentives carried with it brought a markable decline to the quality of the software being produced. We've made strides in righting that ship by returning to proper software development planning methodologies to build good software again (the results we're being paid for), but at the expense of angry PMs who don't see it as fitting their Agile system, which makes for an unhappy work environment. Shame too, as this used to be a really great workplace.
devonkim 8y ago
The advantage I do see for Agile is in shops where management is justified in their belief that developers are being over-cautious as well as too relaxed - this is exactly the atmosphere in many low-throughout software organizations I’ve seen in lots of old, non-software companies. If management is fine with lowering quality in favor of more shinies, Agile is pretty alright - it is Worse is Better codified and institutionalized. If the codebase is so bad it is impeding your ability to deliver business results, you do have justification, but time boxing efforts is important to avoid going down rabbit holes of endless refactoring. I think most of the developers that are hating Agile are probably more disgruntled with their organizations and their culture (usually hostile to high quality engineering in most places fundamentally) than Agile itself. In a way, I think Agile (similar to a lot of automation efforts in infrastructure / IT processes I’ve worked on) simply brings out the true nature and culture of who is driving, who pretends to drive, and where things are falling apart in team dynamics. The software is usually a casualty of bad dynamics is the implication, not bad team members, but we all know this is not true. I think the #1 thing that is missed is that the implementing team should have more control over what they work on. Someone writing a bunch of tickets and pointing them out alone reduces team ownership / responsibility and is pretty much how traditional Taylorist work models are built. Agile is fundamentally much more in line with Deming’s ideas giving much more control to the implementors and that is antithetical to at least 80%+ of businesses in the West and probably Asia too.

by kylnew 8y ago

v1000a 8y ago

I'm not a human resource, thanks. Yes, competent devs hate agile, incompetent talkers love it because it hides their deficiencies and they can shine in the useless meetings.

matthewmacleod 8y ago
That’s a gross oversimplification. I’m a competent, experienced developer. I’be worked in agile, waterfall and “faux-agile” teams. The agile ones have been the best - they adapt quickly to change, have good estimates of progress, and keep all of the team members and wider stakeholders involved in the project. If there are useless meetings in your development team, remove them. If you can’t remove them, then your team is being mismanaged and no form of development methodology will fix that. And also, bear in mind that even among developers on a team there are different sets of skills and preferred working patterns. You may not need some interactions, while other team members benefit from them; remember that the useful measure is the amount of work the team as a whole can achieve!
cc81 8y ago
My experience is that it is more likely that "hero devs" who love to do what they think is important rather than what the team needs will hate any attempt to reign them in.

mathieuh 8y ago

I hate it. Constantly being pressured to move some stupid card or add some stupid tag so people’s graphs look nice. I just want to get work done, Scrum just adds overhead.

cc81 8y ago
How much overhead is it really? 15 minutes a day at most?
- pjmlp 8y ago
  Not if you have the misfortune to be a single developer project or having a lead role on a team. Someone needs to convert those Jira/Trello/Wall/... items into nice Excel sheets because upper management won't look at anything else. While you are at it including some nice Powerpoints for the weekly/monthly updates. And on the remaining time do those development tasks, while coaching junior devs at the same time.
  - mdorazio 8y ago
    If you have a lead role on a team the large majority of your time should be leading the team by doing all those non-development tasks. If you're trying to also cram in mission critical development you're trying to do too much or your company's leadership sucks. If it's a single developer project, 1) Agile might not be the best approach, and 2) updates to management should take very little time since you just need to sum up what you personally have accomplished and are planning to accomplish vs. whatever deadlines exist.
    - pjmlp 8y ago
      That's the nice theory and then there are the actual real life projects, hence why we reached the point discussed on the linked article.
      - mdorazio 8y ago
        Yes, that is the nice theory and also the nice real world. And yes, I've been on and managed dozens of projects at 10+ companies over the last decade so I feel confident saying that. Sounds to me like your company's leadership just sucks. That's not a problem with the methodology.
8y ago

dudul 8y ago

The part I really hate about Agile is how it almost encourages "sloppiness" in requirements (execution too sometimes, but requirements is the part that really drives me crazy). You need to always be "sprinting". There is no time to take a step back and think deeply about the product you are trying to build. No time to think through what a new feature means for your customer and for your existing system. How often do you work on tickets that are completely ironed out? All the actors of the feature are described, all the interactions with their outcomes, all the things to test for, all the new metrics to add to the system? And don't hear me wrong. It's probably the right MO for small companies/products. But once you've reached a certain size for the company, the system and the user base, it's not gonna work. People often laugh at how long it takes for Twitter to introduce a minuscule change in their product, but seriously, I wish a lot of "agile" companies would apply this extreme instead of the completely opposite side of the spectrum: "just start coding this shit, and we'll figure it out later".

randomdata 8y ago

Absolutely. We adopted 'Agile' a little over a year ago and the perverse incentives carried with it brought a markable decline to the quality of the software being produced. We've made strides in righting that ship by returning to proper software development planning methodologies to build good software again (the results we're being paid for), but at the expense of angry PMs who don't see it as fitting their Agile system, which makes for an unhappy work environment. Shame too, as this used to be a really great workplace.

devonkim 8y ago

The advantage I do see for Agile is in shops where management is justified in their belief that developers are being over-cautious as well as too relaxed - this is exactly the atmosphere in many low-throughout software organizations I’ve seen in lots of old, non-software companies. If management is fine with lowering quality in favor of more shinies, Agile is pretty alright - it is Worse is Better codified and institutionalized. If the codebase is so bad it is impeding your ability to deliver business results, you do have justification, but time boxing efforts is important to avoid going down rabbit holes of endless refactoring. I think most of the developers that are hating Agile are probably more disgruntled with their organizations and their culture (usually hostile to high quality engineering in most places fundamentally) than Agile itself. In a way, I think Agile (similar to a lot of automation efforts in infrastructure / IT processes I’ve worked on) simply brings out the true nature and culture of who is driving, who pretends to drive, and where things are falling apart in team dynamics. The software is usually a casualty of bad dynamics is the implication, not bad team members, but we all know this is not true. I think the #1 thing that is missed is that the implementing team should have more control over what they work on. Someone writing a bunch of tickets and pointing them out alone reduces team ownership / responsibility and is pretty much how traditional Taylorist work models are built. Agile is fundamentally much more in line with Deming’s ideas giving much more control to the implementors and that is antithetical to at least 80%+ of businesses in the West and probably Asia too.