4 ms·

That is exactly how I see and have experienced it as well. It's part of why I called it a motivation killer but I didn't go into more detail. Not only because

by Meai 9y ago

That is exactly how I see and have experienced it as well. It's part of why I called it a motivation killer but I didn't go into more detail. Not only because of the accusatory thing but also I actually like to surprise my colleagues with cool features and issues I solve, surprising them with my speed even. If I attend a standup, I need to report that I'm working on these things so the surprise is gone. All my motivation to get them done asap is gone. Likewise, I can't do my own "secret" time planning anymore. I like to finish some mandatory feature fast so I can squeeze in a little extra cool thing I wanted to do for a long time. If I have to explain and justify this stuff, the manager will step in and urge me to do other mandatory things instead. It's such a mindkiller.

bhauer 9y ago
When I manage teams, I love having productive and self-motivated people like yourself on the team. As long as you are able to complete the scheduled and required tasks, if by being light-touch with process, you are motivated to contribute above and beyond, the whole team reaps dividends. I have seen such members contribute great tooling upgrades, features to reduce administrative overhead, automation mechanisms, and even delightful user-facing features. In my opinion, processes are designed to resolve or prevent dysfunction. An extra-productive team member that completes assigned tasks and adds in some of their own creativity on top is generally not a source of dysfunction, so I prefer to encumber such people with as little process as feasible. I for one love engaged productive developers who deliver bonus features of the sort I mentioned above and I find over-processing curtails those bonuses.
SimonPStevens 9y ago
This is exactly why you should be in a standup. "Secret" time planning and developing "cool" features. Someone has taken the time to carefully plan the features required for a project and make projections of how long that will take and how much it will cost. There may have been customer feedback on what features are required, or possibly even a customer is paying the costs of certain development work. And you think it's your job to just secretly decide that you don't want to do that, you'd rather spend time working on something cooler that the customers might not even want or perhaps conflicts with other project plans. I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation. The last thing I want is to be surprised by a new feature just showing up unplanned in a project. I dunno, perhaps you work on internal software for a small group of specific known users who sit a few desks away from you and that's acceptable to them, but for any team building a customer facing product that attitude would be a nightmare to manage.
- deleted 9y ago
  [deleted]
- lj3 9y ago
  > I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation. When the managers stop doing this, we'll stop doing this. This adversity between engineers and management is one of the biggest reasons I hate the agile process as it is commonly practiced. It benefits management at the expense of engineering, thus creating animosity between two groups who are supposed to be working together.

by Meai 9y ago

bhauer 9y ago

When I manage teams, I love having productive and self-motivated people like yourself on the team. As long as you are able to complete the scheduled and required tasks, if by being light-touch with process, you are motivated to contribute above and beyond, the whole team reaps dividends. I have seen such members contribute great tooling upgrades, features to reduce administrative overhead, automation mechanisms, and even delightful user-facing features. In my opinion, processes are designed to resolve or prevent dysfunction. An extra-productive team member that completes assigned tasks and adds in some of their own creativity on top is generally not a source of dysfunction, so I prefer to encumber such people with as little process as feasible. I for one love engaged productive developers who deliver bonus features of the sort I mentioned above and I find over-processing curtails those bonuses.

SimonPStevens 9y ago

This is exactly why you should be in a standup. "Secret" time planning and developing "cool" features. Someone has taken the time to carefully plan the features required for a project and make projections of how long that will take and how much it will cost. There may have been customer feedback on what features are required, or possibly even a customer is paying the costs of certain development work. And you think it's your job to just secretly decide that you don't want to do that, you'd rather spend time working on something cooler that the customers might not even want or perhaps conflicts with other project plans. I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation. The last thing I want is to be surprised by a new feature just showing up unplanned in a project. I dunno, perhaps you work on internal software for a small group of specific known users who sit a few desks away from you and that's acceptable to them, but for any team building a customer facing product that attitude would be a nightmare to manage.

deleted 9y ago
[deleted]
lj3 9y ago
> I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation. When the managers stop doing this, we'll stop doing this. This adversity between engineers and management is one of the biggest reasons I hate the agile process as it is commonly practiced. It benefits management at the expense of engineering, thus creating animosity between two groups who are supposed to be working together.