6 ms·

I think there's a bit of learned helplessness, but I also think that a lot of this is because of agile (or more specifically, scrum), not in spite of it. The a

I think there's a bit of learned helplessness, but I also think that a lot of this is because of agile (or more specifically, scrum), not in spite of it. The amount of micro-management that goes into most programmers day to day work makes it extremely hard to be innovative, because you essentially have to justify what you're working on daily -- and any creative person knows that not every idea pans out. You need managerial support to occasionally make mistakes. There have been a lot of times in other jobs where we'd have a slack in our schedule and I used the down time to make a change that was really necessary and took a minimal amount of time, mentioned it in a standup meeting, and got blasted for not working on our "commitments" for the "sprint" (even when I had nothing to do). Companies always talk about wanting ideas from workers and how important innovation is, but they're not willing to extend the trust to their people to create an environment where that can happen. People naturally become disengaged when they're not trusted or valued. The worst part is that it's not just management creating this mentality, it's the other programmers. I've noticed that younger more inexperienced programmers tend to crave the structure of agile, whereas the older more experienced programmers chafe at it. I think if programming had more of a culture of apprenticeship and mentorship, and a deeper appreciation that this is hard and it takes a long time to get good at it, our industry would be a lot healthier.

vvanders 9y ago
That sounds like poorly run scrum more than anything else. I can't count the number of times I've thrown an "investigation" task on the backlog that may or may not have panned out. Scrum is more about keeping your fellow engineers informed on what they are working on so incompatible things rise quickly. It shouldn't be used as a tool for micro management but instead reviewed at the end of each sprint.
- OnlyRepliesToBS 9y ago
  > You're doing it wrong. This is the nonfalsifiability of a religion surfacing. THIS is the problem. This very thing. The implement is ALWAYS blamed.
- zukzuk 9y ago
  And this is exactly why "agile" has become a religion more than anything — if it's not working, it's because you're doing it wrong. You just need to agile harder.
  - vvanders 9y ago
    Well, there are no absolutes in this industry, if there were then we all wouldn't have a job since it would just be paint by numbers. If a process isn't getting you what you want then change it. Is it any wonder that repeating a broken process gets you broken results each time?
  - Bahamut 9y ago
    To be fair, it really does sound like bad management - management shouldn’t be blasting an individual during scrum. Management also shouldn’t care if other work gets done as long as the core commitments get finished. Good management shouldn’t hamstring you like that - engineering doesn’t work like that. That is regardless of agile or whatever development methodology you use.
    - TheCoelacanth 9y ago
      Management really shouldn't even be participating in any of the scrum meetings other than the sprint review. All of the other meetings are supposed to be just for the team itself.
  - scarface74 9y ago
    I've never seen agile work with sprints. Things change too fast and usually there are unknowns. I have seen Kanban work because it takes into account the reality that priorities change, and estimates are never accurate. I am also a big believer in hard short deadlines when it comes to doing releases. When the deadline comes, release what you have ready and put it behind a feature toggle if needed to do a phased rollout.
  - koonsolo 9y ago
    If it's not working, why isn't it addressed in the retrospective? If you have a proper retrospective, you can change anything, even going from scrum to kanban.
- Retra 9y ago
  There is very little you have to add to "keeping everyone informed of what you are doing" to end up at micromanagement.
  - vvanders 9y ago
    Notice I said engineers and not management or everyone, very small but important difference.
    - overgard 9y ago
      The thing is though, the number of times I've seen engineers work on conflicting/redundant things without realizing it (outside of the agile/scrum environment) has been vanishingly small. And the places I've seen it it's always been on separate teams that would never have been part of the same scrum group in the first place (ie, it was an inter-team problem rather than an intra-team problem)
      - CountSessine 9y ago
        This rings true for me. At one of my former employers our scrum masters came up with this idea of a ‘scrum-of-scrums’ where team leads would get together once every month and have a standup to talk about things they’re working on that could affect other teams. But it became a painful waste of time because some of the participants didn’t understand that we didn’t want to hear them talk about every single task their team worked on. Then we tried ‘release-train’ planning where the whole company would do 2 day company-stand ups. That was even worse. The real problem was that the company had a weird cultural and engineering mismatch between hardware and software engineers and the upper management was too clueless and careless to coordinate between them.
- overgard 9y ago
  The problem with "investigation" tasks or "spikes" is that it still boils down to essentially having to ask permission to do something. I really think extreme one-sided work transparency and a culture where everything is measured and permission has to be sought to work on something is entirely antithetical to encouraging creativity. Innovation tends to come from playfulness, and having to schedule a Jira task with a project manager for every idea is going to have a chilling effect.
  - goalieca 9y ago
    You’ve hit my first main point of hatred against agile. It’s really a form of micromanaging in disguise. They sell it as developer empowerment but that’s just cognitive dissonance.
    - YeGoblynQueenne 9y ago
      That depends on the company. Some companies (in my experience) do engineer-only scrums where programmers can talk about their blockers and ask for advice from seniors; others do mixed scrums where the engineers are basically reporting their progress to the product manager or someone, and where often technical questions are discouraged. I'd tend to think the latter are "doing it wrong", but then again, who am I to say? I just know I much preferred working for the companies who did it the former way.
      - watwut 9y ago
        This idea that only managers micromanage and fellow engineers never do that us one of biggest agile fallacies. Also, need to ask question should not require whole team meeting.
    - mmcnl 9y ago
      This is not a problem of agile, it's a problem with the implementation of agile. A company that tends to micromanage that implements agile will use agile to micromanage. It's unavoidable.
- lliamander 9y ago
  When I've done R&D in an agile setting, usually the research was done outside of the scrum process, and once that was done then the development would be done in a standard scrum methodology. The reason you can't really apply "Agile" to research is that having a useful product at the end of each sprint is a central to Agile development but runs contrary to the purpose of research. Now, you still need to manage your research process. You need to identify the specific research questions you need to answer, and you need to bound the time investment. But let's not try too hard to shoehorn a methodology primarily oriented towards IT consulting into every other domain.
- 0x445442 9y ago
  How many points did you give those tasks? We're the points agreed upon by the team? Did the team and the business agree to the tasks being included in the Sprint during Sprint planning? It sounds like you created the tasks yourself and added them to the backlog mid-sprint. If that's what you did I'd be totally cool with it but I can tell you a lot of "agile shops" would blow a gasket over that.
gdubs 9y ago
Having been on a lot of teams with various processes, it seems to ultimately come down to trust. I’ve seen teams where there’s a ton of trust and mutual respect, where even a very structured agile approach has allowed for sprints focused entirely on innovation and exploration. Process is just another tool; how it’s used — and the environment — matters a lot.
- gurkendoktor 9y ago
  I think the flip side of this is that Agile does not add much in the best case (people trust each other), but it can cause a lot of damage in the worst case (nobody trusts each other, but people can be productive thanks to a lack of transparency).
LrnByTeach 9y ago
> The amount of micro-management that goes into most programmers day to day work makes it extremely hard to be innovative, because you essentially have to justify what you're working on daily -- and any creative person knows that not every idea pans out. You need managerial support to occasionally make mistakes. There have been a lot of times in other jobs where we'd have a slack in our schedule and I used the down time to make a change that was really necessary and took a minimal amount of time, mentioned it in a standup meeting, and got blasted for not working on our "commitments" for the "sprint" (even when I had nothing to do). > The worst part is that it's not just management creating this mentality, it's the other programmers. I've noticed that younger more inexperienced programmers tend to crave the structure of agile, whereas the older more experienced programmers chafe at it. > I think if programming had more of a culture of apprenticeship and mentorship, and a deeper appreciation that this is hard and it takes a long time to get good at it, our industry would be a lot healthier.
NPMaxwell 9y ago
Yes! You're right that companies say they want ideas and then dismiss them, and that this is something co-workers often do to each other. I doubt this is a scrum/not-scrum issue. I think a manager (or master) can be dismissive within almost any work organization structure. The example you give looks like someone a) feeling entitled to blast you (What gave them that idea!?! I'm not an agile expert, but I'm sure "Chew people out" is not a part agile.) b) They blasted before understanding your thinking and decision making, thereby appearing to be stupid to you and to all us Hacker News readers years later.
dlandis 9y ago
> There have been a lot of times in other jobs where we'd have a slack in our schedule and I used the down time to make a change that was really necessary and took a minimal amount of time, mentioned it in a standup meeting, and got blasted for not working on our "commitments" for the "sprint" (even when I had nothing to do). That doesn't really have anything to do with agile or scrum though. Just add a refactor/investigation task to the backlog for the sprint. Those types of activities should be justifiable too. If your team doesn't allow those types of tasks for some reason, that's more of a team problem than a problem with agile.
- overgard 9y ago
  "Justifiable" is the key word though. Why do I need to justify what I'm working on daily unless I'm not trusted? I mean, like most programmers, I have a four year computer science degree that was definitely not easy to obtain, I have like 10 years of experience, I've shown an understanding for prioritizing things that actually are important for the business, and they pay me a six figure salary for my expertise, so having to justify myself daily seems, frankly, insulting. I've worked in places where I didn't have to do that, and you know what? The sky didn't fall. Work still got done. (I would argue, more work, because people were more engaged since they felt a sense of ownership). We just had extra time in the day from fewer useless meetings, and a lot less politics from people trying to game the numbers they pull out of Jira and stuff like that.
  - solipsism 9y ago
    This is a toxic attitude. Your 10 years of experience and 4 year education don't make you infallible. A high functioning team works closely, and that involves everyone's decisions being subject to scrutiny. If you can't justify your work, then it probably shouldn't get done. If you won't justify your work, then you don't deserve the six figures.
    - overgard 9y ago
      I never claimed to be infallible, and I'm happy to explain what I'm doing if someone asks, but ask yourself, how many other skilled highly educated professions are asked to provide such a humiliating measure of unnecessary transparency? (Hint: not most of them). Does your manager give you such transparency into what they're doing day to day? (Generally speaking: nope!) How do I know they're not just spending their afternoon's playing golf? (I don't: but I wouldn't work for them if I didn't think they were mature capable professionals). Think of it this way, in relationships, business or otherwise, what's sub-communicated is just as important as what's explicitly communicated. Often it's more important. And what's communicated via most agile processes is that programmers are unimportant cogs with no business knowledge that can't be trusted to not stray from important tasks. I think that's ugly.
0x445442 9y ago
This is spot on. It's the Enterprise's Holy Grail; the attempt to commoditize software development.

vvanders 9y ago

That sounds like poorly run scrum more than anything else. I can't count the number of times I've thrown an "investigation" task on the backlog that may or may not have panned out. Scrum is more about keeping your fellow engineers informed on what they are working on so incompatible things rise quickly. It shouldn't be used as a tool for micro management but instead reviewed at the end of each sprint.

OnlyRepliesToBS 9y ago
> You're doing it wrong. This is the nonfalsifiability of a religion surfacing. THIS is the problem. This very thing. The implement is ALWAYS blamed.
zukzuk 9y ago
And this is exactly why "agile" has become a religion more than anything — if it's not working, it's because you're doing it wrong. You just need to agile harder.
- vvanders 9y ago
  Well, there are no absolutes in this industry, if there were then we all wouldn't have a job since it would just be paint by numbers. If a process isn't getting you what you want then change it. Is it any wonder that repeating a broken process gets you broken results each time?
- Bahamut 9y ago
  To be fair, it really does sound like bad management - management shouldn’t be blasting an individual during scrum. Management also shouldn’t care if other work gets done as long as the core commitments get finished. Good management shouldn’t hamstring you like that - engineering doesn’t work like that. That is regardless of agile or whatever development methodology you use.
  - TheCoelacanth 9y ago
    Management really shouldn't even be participating in any of the scrum meetings other than the sprint review. All of the other meetings are supposed to be just for the team itself.
- scarface74 9y ago
  I've never seen agile work with sprints. Things change too fast and usually there are unknowns. I have seen Kanban work because it takes into account the reality that priorities change, and estimates are never accurate. I am also a big believer in hard short deadlines when it comes to doing releases. When the deadline comes, release what you have ready and put it behind a feature toggle if needed to do a phased rollout.
- koonsolo 9y ago
  If it's not working, why isn't it addressed in the retrospective? If you have a proper retrospective, you can change anything, even going from scrum to kanban.
Retra 9y ago
There is very little you have to add to "keeping everyone informed of what you are doing" to end up at micromanagement.
- vvanders 9y ago
  Notice I said engineers and not management or everyone, very small but important difference.
  - overgard 9y ago
    The thing is though, the number of times I've seen engineers work on conflicting/redundant things without realizing it (outside of the agile/scrum environment) has been vanishingly small. And the places I've seen it it's always been on separate teams that would never have been part of the same scrum group in the first place (ie, it was an inter-team problem rather than an intra-team problem)
    - CountSessine 9y ago
      This rings true for me. At one of my former employers our scrum masters came up with this idea of a ‘scrum-of-scrums’ where team leads would get together once every month and have a standup to talk about things they’re working on that could affect other teams. But it became a painful waste of time because some of the participants didn’t understand that we didn’t want to hear them talk about every single task their team worked on. Then we tried ‘release-train’ planning where the whole company would do 2 day company-stand ups. That was even worse. The real problem was that the company had a weird cultural and engineering mismatch between hardware and software engineers and the upper management was too clueless and careless to coordinate between them.
overgard 9y ago
The problem with "investigation" tasks or "spikes" is that it still boils down to essentially having to ask permission to do something. I really think extreme one-sided work transparency and a culture where everything is measured and permission has to be sought to work on something is entirely antithetical to encouraging creativity. Innovation tends to come from playfulness, and having to schedule a Jira task with a project manager for every idea is going to have a chilling effect.
- goalieca 9y ago
  You’ve hit my first main point of hatred against agile. It’s really a form of micromanaging in disguise. They sell it as developer empowerment but that’s just cognitive dissonance.
  - YeGoblynQueenne 9y ago
    That depends on the company. Some companies (in my experience) do engineer-only scrums where programmers can talk about their blockers and ask for advice from seniors; others do mixed scrums where the engineers are basically reporting their progress to the product manager or someone, and where often technical questions are discouraged. I'd tend to think the latter are "doing it wrong", but then again, who am I to say? I just know I much preferred working for the companies who did it the former way.
    - watwut 9y ago
      This idea that only managers micromanage and fellow engineers never do that us one of biggest agile fallacies. Also, need to ask question should not require whole team meeting.
  - mmcnl 9y ago
    This is not a problem of agile, it's a problem with the implementation of agile. A company that tends to micromanage that implements agile will use agile to micromanage. It's unavoidable.
lliamander 9y ago
When I've done R&D in an agile setting, usually the research was done outside of the scrum process, and once that was done then the development would be done in a standard scrum methodology. The reason you can't really apply "Agile" to research is that having a useful product at the end of each sprint is a central to Agile development but runs contrary to the purpose of research. Now, you still need to manage your research process. You need to identify the specific research questions you need to answer, and you need to bound the time investment. But let's not try too hard to shoehorn a methodology primarily oriented towards IT consulting into every other domain.
0x445442 9y ago
How many points did you give those tasks? We're the points agreed upon by the team? Did the team and the business agree to the tasks being included in the Sprint during Sprint planning? It sounds like you created the tasks yourself and added them to the backlog mid-sprint. If that's what you did I'd be totally cool with it but I can tell you a lot of "agile shops" would blow a gasket over that.

gdubs 9y ago

Having been on a lot of teams with various processes, it seems to ultimately come down to trust. I’ve seen teams where there’s a ton of trust and mutual respect, where even a very structured agile approach has allowed for sprints focused entirely on innovation and exploration. Process is just another tool; how it’s used — and the environment — matters a lot.

gurkendoktor 9y ago
I think the flip side of this is that Agile does not add much in the best case (people trust each other), but it can cause a lot of damage in the worst case (nobody trusts each other, but people can be productive thanks to a lack of transparency).

LrnByTeach 9y ago

> The amount of micro-management that goes into most programmers day to day work makes it extremely hard to be innovative, because you essentially have to justify what you're working on daily -- and any creative person knows that not every idea pans out. You need managerial support to occasionally make mistakes. There have been a lot of times in other jobs where we'd have a slack in our schedule and I used the down time to make a change that was really necessary and took a minimal amount of time, mentioned it in a standup meeting, and got blasted for not working on our "commitments" for the "sprint" (even when I had nothing to do). > The worst part is that it's not just management creating this mentality, it's the other programmers. I've noticed that younger more inexperienced programmers tend to crave the structure of agile, whereas the older more experienced programmers chafe at it. > I think if programming had more of a culture of apprenticeship and mentorship, and a deeper appreciation that this is hard and it takes a long time to get good at it, our industry would be a lot healthier.

NPMaxwell 9y ago

Yes! You're right that companies say they want ideas and then dismiss them, and that this is something co-workers often do to each other. I doubt this is a scrum/not-scrum issue. I think a manager (or master) can be dismissive within almost any work organization structure. The example you give looks like someone a) feeling entitled to blast you (What gave them that idea!?! I'm not an agile expert, but I'm sure "Chew people out" is not a part agile.) b) They blasted before understanding your thinking and decision making, thereby appearing to be stupid to you and to all us Hacker News readers years later.

dlandis 9y ago

> There have been a lot of times in other jobs where we'd have a slack in our schedule and I used the down time to make a change that was really necessary and took a minimal amount of time, mentioned it in a standup meeting, and got blasted for not working on our "commitments" for the "sprint" (even when I had nothing to do). That doesn't really have anything to do with agile or scrum though. Just add a refactor/investigation task to the backlog for the sprint. Those types of activities should be justifiable too. If your team doesn't allow those types of tasks for some reason, that's more of a team problem than a problem with agile.

overgard 9y ago
"Justifiable" is the key word though. Why do I need to justify what I'm working on daily unless I'm not trusted? I mean, like most programmers, I have a four year computer science degree that was definitely not easy to obtain, I have like 10 years of experience, I've shown an understanding for prioritizing things that actually are important for the business, and they pay me a six figure salary for my expertise, so having to justify myself daily seems, frankly, insulting. I've worked in places where I didn't have to do that, and you know what? The sky didn't fall. Work still got done. (I would argue, more work, because people were more engaged since they felt a sense of ownership). We just had extra time in the day from fewer useless meetings, and a lot less politics from people trying to game the numbers they pull out of Jira and stuff like that.
- solipsism 9y ago
  This is a toxic attitude. Your 10 years of experience and 4 year education don't make you infallible. A high functioning team works closely, and that involves everyone's decisions being subject to scrutiny. If you can't justify your work, then it probably shouldn't get done. If you won't justify your work, then you don't deserve the six figures.
  - overgard 9y ago
    I never claimed to be infallible, and I'm happy to explain what I'm doing if someone asks, but ask yourself, how many other skilled highly educated professions are asked to provide such a humiliating measure of unnecessary transparency? (Hint: not most of them). Does your manager give you such transparency into what they're doing day to day? (Generally speaking: nope!) How do I know they're not just spending their afternoon's playing golf? (I don't: but I wouldn't work for them if I didn't think they were mature capable professionals). Think of it this way, in relationships, business or otherwise, what's sub-communicated is just as important as what's explicitly communicated. Often it's more important. And what's communicated via most agile processes is that programmers are unimportant cogs with no business knowledge that can't be trusted to not stray from important tasks. I think that's ugly.

0x445442 9y ago

This is spot on. It's the Enterprise's Holy Grail; the attempt to commoditize software development.