4 ms·

I'm really curious, could you expand on why do you think it was more motivating? Were there less micromanagement before agile?

rramadass 5y ago
The book Why We Do What We Do: Understanding Self-Motivation by Edward Deci may give you some answers. The key thing a "Knowledge Worker" needs/demands is Autonomy over his own Work/Decisions (within the context of the larger problem). In the old days, we had the Freedom along with the Accountability. What Agile/Scrum has done is taken away our Freedom but by micromanaging our day-to-day activities has increased our Accountability. This is completely unjustifiable and unacceptable. PS: An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only - Bjarne Stroustrup.
watwut 5y ago
I think it comes back to "autonomy, mastery, accountability". You was responsible for bigger chunks of work. You had more autonomy within that chunk - you could make at least some decisions independently. Whether they were bad or good, it was clear they were yours. You could also have some sense of control over your work - you could use own brain to plan and prioritize within that chunk. Consequently, you felt like you have done and achieved something. You also could create something coherent. Also, over time you became better and better at the thing you was doing. You was thinking about module or project as a whole. With agile, I feel mostly like cross between factory worker middle management politician. Every little detail has to be negotiated with multiple people and half success is guessing what is on their minds. You work on tiny tasks. You dont get sense of achievement, you just use your hammer to put in nail here, then paint a bit over there.
- rchaves 5y ago
  Weird because that’s exactly the points I feel agile should be help with. In the teams I’m in I always promote the whole team should be part of deciding what to do, prioritizing, and coming up with ideas of valuable things to do, I speak up and give bad feedbacks to PMs that monopolize the decisions Also the team itself should be very autonomous inside the organization as much as your context allows. In fact, the company I work for had fully independent teams in startup mode for so long, that eventually they started to step on each other toes, there was very few alignment. As company grew, more alignment and therefore negotiations started to be needed but I don’t see much way around that other than staying small and horizontal (which I like too). Still, on parts of the company on “exploration mode” (from Kent Beck’s 3X model), teams still remain very autonomous As for the small tasks, I see them as a way exactly to promote a sense of achievement, the team is responsible for this big chunk of work and you should be able to see very clearly how things are moving forward. Sure, if you lose connection with the bigger picture because you or your team does not have enough autonomy, then something is wrong and you need to fix it, otherwise you lose this effect.
  - watwut 5y ago
    > In the teams I’m in I always promote the whole team should be part of deciding what to do, prioritizing, and coming up with ideas of valuable things to do, I speak up and give bad feedbacks to PMs that monopolize the decisions Otherwise said, all those decisions are done by committee. None of them can be done by any employee autonomously and no employee gets to have responsibility. You never do those things nebulous, notion of "team" does. But team is not you, it is group of people. All the situations you described are negotiation between many parties situations. Also, micromanagement or decisions monopolization can be done by anyone on any level. Many developers love to do so - and exactly these do love agile, because that gives them cover to railroad everyone else. Agile is really big on making PM or management enemies. It does work to some extend, common enemy does bring people together. > Also the team itself should be very autonomous inside the organization as much as your context allows. And no single team member has no area of responsibility or autonomy. And that is the thing - if you like to dominate and influence other people, agile gives you plenty of playground. If you like to throw your weight in the meetings, great. But if you dont want to do that constantly all the time, you are expected to be passive follower with no space for any autonomy, mastery nor accountability. > As for the small tasks, I see them as a way exactly to promote a sense of achievement, the team is responsible for this big chunk of work and you should be able to see very clearly how things are moving forward. Sure, if you lose connection with the bigger picture because you or your team does not have enough autonomy, then something is wrong and you need to fix it, otherwise you lose this effect. Note how it is still the "team". You don't see nor mention any individual. No individual at that team achieved anything personally. Individuals almost don't exist. They did not made single tiny decisions that would not been discussed to death with five other people. For a methodic that is supposed to favor individuals, there is literally zero concern for individual or human psychology. The only interest is in group.
    - rchaves 5y ago
      The small decisions should be made by the individuals of course, as group decisions are too expensive, but the bigger ones should be taken by the team, where it pays off, or at least a pair. I’ve dealt too much with bus factor problems in the past to want fully individual systems It also happens on scrum teams a lot, the engineer the built certain part of the system is the only one to ever take tasks related to it and the only one that knows how to fix it, so when they are gone you have to deal with their mess On XP pair programming solves that very nicely, with a lot of comradery, but then you may also argue there is not enough individuality

rramadass 5y ago

The book Why We Do What We Do: Understanding Self-Motivation by Edward Deci may give you some answers. The key thing a "Knowledge Worker" needs/demands is Autonomy over his own Work/Decisions (within the context of the larger problem). In the old days, we had the Freedom along with the Accountability. What Agile/Scrum has done is taken away our Freedom but by micromanaging our day-to-day activities has increased our Accountability. This is completely unjustifiable and unacceptable. PS: An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only - Bjarne Stroustrup.

watwut 5y ago

I think it comes back to "autonomy, mastery, accountability". You was responsible for bigger chunks of work. You had more autonomy within that chunk - you could make at least some decisions independently. Whether they were bad or good, it was clear they were yours. You could also have some sense of control over your work - you could use own brain to plan and prioritize within that chunk. Consequently, you felt like you have done and achieved something. You also could create something coherent. Also, over time you became better and better at the thing you was doing. You was thinking about module or project as a whole. With agile, I feel mostly like cross between factory worker middle management politician. Every little detail has to be negotiated with multiple people and half success is guessing what is on their minds. You work on tiny tasks. You dont get sense of achievement, you just use your hammer to put in nail here, then paint a bit over there.

rchaves 5y ago
Weird because that’s exactly the points I feel agile should be help with. In the teams I’m in I always promote the whole team should be part of deciding what to do, prioritizing, and coming up with ideas of valuable things to do, I speak up and give bad feedbacks to PMs that monopolize the decisions Also the team itself should be very autonomous inside the organization as much as your context allows. In fact, the company I work for had fully independent teams in startup mode for so long, that eventually they started to step on each other toes, there was very few alignment. As company grew, more alignment and therefore negotiations started to be needed but I don’t see much way around that other than staying small and horizontal (which I like too). Still, on parts of the company on “exploration mode” (from Kent Beck’s 3X model), teams still remain very autonomous As for the small tasks, I see them as a way exactly to promote a sense of achievement, the team is responsible for this big chunk of work and you should be able to see very clearly how things are moving forward. Sure, if you lose connection with the bigger picture because you or your team does not have enough autonomy, then something is wrong and you need to fix it, otherwise you lose this effect.
- watwut 5y ago
  > In the teams I’m in I always promote the whole team should be part of deciding what to do, prioritizing, and coming up with ideas of valuable things to do, I speak up and give bad feedbacks to PMs that monopolize the decisions Otherwise said, all those decisions are done by committee. None of them can be done by any employee autonomously and no employee gets to have responsibility. You never do those things nebulous, notion of "team" does. But team is not you, it is group of people. All the situations you described are negotiation between many parties situations. Also, micromanagement or decisions monopolization can be done by anyone on any level. Many developers love to do so - and exactly these do love agile, because that gives them cover to railroad everyone else. Agile is really big on making PM or management enemies. It does work to some extend, common enemy does bring people together. > Also the team itself should be very autonomous inside the organization as much as your context allows. And no single team member has no area of responsibility or autonomy. And that is the thing - if you like to dominate and influence other people, agile gives you plenty of playground. If you like to throw your weight in the meetings, great. But if you dont want to do that constantly all the time, you are expected to be passive follower with no space for any autonomy, mastery nor accountability. > As for the small tasks, I see them as a way exactly to promote a sense of achievement, the team is responsible for this big chunk of work and you should be able to see very clearly how things are moving forward. Sure, if you lose connection with the bigger picture because you or your team does not have enough autonomy, then something is wrong and you need to fix it, otherwise you lose this effect. Note how it is still the "team". You don't see nor mention any individual. No individual at that team achieved anything personally. Individuals almost don't exist. They did not made single tiny decisions that would not been discussed to death with five other people. For a methodic that is supposed to favor individuals, there is literally zero concern for individual or human psychology. The only interest is in group.
  - rchaves 5y ago
    The small decisions should be made by the individuals of course, as group decisions are too expensive, but the bigger ones should be taken by the team, where it pays off, or at least a pair. I’ve dealt too much with bus factor problems in the past to want fully individual systems It also happens on scrum teams a lot, the engineer the built certain part of the system is the only one to ever take tasks related to it and the only one that knows how to fix it, so when they are gone you have to deal with their mess On XP pair programming solves that very nicely, with a lot of comradery, but then you may also argue there is not enough individuality