5 ms·

I never understood the obsession with this kind of thing. I guess it’s important to project managers and the like, but as a software developer? Just give me a l

I never understood the obsession with this kind of thing. I guess it’s important to project managers and the like, but as a software developer? Just give me a list of prioritised tasks. You want me to be in a stand up saying what I did yesterday, what I’ll do today and what are the blockers? Fine, I’ll do that as long as the whole thing doesn’t take longer than 15 mins and you let me focus aftwewards.

siva7 2y ago
> Just give me a list of prioritised tasks. The role of a modern Software developer is changing and Scrum is accommodating that fact. If you just want a task list, start coding and be left alone, that's fine, then you should look out for teams who don't do modern/agile software development. I've had my fair share of such developer types in my career and i would have just wished that they didn't have signed the work contract as they pretty much knew beforehand that they dislike agile but kept that for themselves until after the fact.
- convolvatron 2y ago
  'agile' can mean anything from a slightly reductive but generally useful process to a mind numbing waste of time where no one is really allowed to do anything at all except talk about the work they're ostensibly supposed to be doing. if hiring companies were more clear, we could steer well clear of the latter. but they all say 'oh, yeah, we just have a lightweight agile process, not really a big deal, we're trying to do it right, not like those other terrible people'. everyone whose been in the industry knows how to deal with the former. look, if you need daily status from me that i'm not just going to volunteer anyways, fine, its not a huge overhead. if you me to track my work with tickets, not gonna kill me. if you want me to meet every two weeks to make some plans, i can do that. thats not what people have a problem with. not being able to actually make plans because we're supposed to come up with our own sprint goals is. spending 1 week out of every two 'planning' is. aurguing about the proper number of story points for a given task is. incessantly arguing about how we can cut up the work so it it nicely fits into 3-4 stories per sprint or whatever management wants is. at some point the management narrative completely overwhelms the actual work at hand. omg i forgot some of the even bigger ones. expecting me to squeeze in all the other parts of my job like mentoring new hires or meeting with product or responding to issues in prod without messing up your sprint schedule. or undermining my ability to make any plans longer than a sprint because that contradicts your desire to tell simple stories and interchange workers.
BlackFly 2y ago
Meanwhile, I have never understood positions like this. What exactly does ideal team work look like to you? Do you collaborate with your teammates or do you all go off and work on completely isolated tasks? Do you only share knowledge after the fact through code reviews or do you manage to spontaneously talk about how to accomplish big things before the tasks are assigned? Do you routinely communicate with your users or representatives thereof or do they spontaneously show up and let you know about the actual problems they have and how things are going? Is the application you are building so simple that you are the only person working on it otherwise why is a ratio of 1:31 an effective ratio of collaboration for you? From my perspective, well functioning teams communicate with each frequently. What's the daily, short term (spring), long term plan? Why did that last plan go well/wrong and what should we do differently? Routine meetings have a habit of becoming rote, but it is difficult to ensure such conversations are spontaneously happening between more than a couple of people. I don't want my colleagues to be surprised when they review my implementation, so we need to discuss it before I do it and vice versa. Discussing those things ahead of times also allows us to plan and prioritize more effectively. It also helps us align and build a better understanding of what we are doing. I think people are obsessed with this kind of thing because people quest for a silver bullet, but individual teams working on disparate products and problems will find different strategies more effective and require a different balance of communication. Meanwhile, most organizations will push a chosen silver bullet in the name of consistency instead of enabling teams to truly self organize.
- Xenoamorphous 2y ago
  > What exactly does ideal team work look like to you? Certainly not something defined/constrained by the PM methodology du jour. I can and do reach my teammates frequently just like they do with me. This doesn’t preclude the occasional meeting or even the daily stand up, as I said. But in the end I want to know what I have to work on and who I have to reach if I need help or get blocked, and more importantly, be given the focus time to do it.
  - skydhash 2y ago
    This. And I’ll be amenable to a team meeting to reflect and exchange on how the team have been doing. And even those demo meetings when a project got done. Or sharing knowledge and doing postmortems. I just don’t want the daily standups and the ritual retros. I never wait for these to share issues and provide updates.

siva7 2y ago

> Just give me a list of prioritised tasks. The role of a modern Software developer is changing and Scrum is accommodating that fact. If you just want a task list, start coding and be left alone, that's fine, then you should look out for teams who don't do modern/agile software development. I've had my fair share of such developer types in my career and i would have just wished that they didn't have signed the work contract as they pretty much knew beforehand that they dislike agile but kept that for themselves until after the fact.

convolvatron 2y ago
'agile' can mean anything from a slightly reductive but generally useful process to a mind numbing waste of time where no one is really allowed to do anything at all except talk about the work they're ostensibly supposed to be doing. if hiring companies were more clear, we could steer well clear of the latter. but they all say 'oh, yeah, we just have a lightweight agile process, not really a big deal, we're trying to do it right, not like those other terrible people'. everyone whose been in the industry knows how to deal with the former. look, if you need daily status from me that i'm not just going to volunteer anyways, fine, its not a huge overhead. if you me to track my work with tickets, not gonna kill me. if you want me to meet every two weeks to make some plans, i can do that. thats not what people have a problem with. not being able to actually make plans because we're supposed to come up with our own sprint goals is. spending 1 week out of every two 'planning' is. aurguing about the proper number of story points for a given task is. incessantly arguing about how we can cut up the work so it it nicely fits into 3-4 stories per sprint or whatever management wants is. at some point the management narrative completely overwhelms the actual work at hand. omg i forgot some of the even bigger ones. expecting me to squeeze in all the other parts of my job like mentoring new hires or meeting with product or responding to issues in prod without messing up your sprint schedule. or undermining my ability to make any plans longer than a sprint because that contradicts your desire to tell simple stories and interchange workers.

BlackFly 2y ago

Meanwhile, I have never understood positions like this. What exactly does ideal team work look like to you? Do you collaborate with your teammates or do you all go off and work on completely isolated tasks? Do you only share knowledge after the fact through code reviews or do you manage to spontaneously talk about how to accomplish big things before the tasks are assigned? Do you routinely communicate with your users or representatives thereof or do they spontaneously show up and let you know about the actual problems they have and how things are going? Is the application you are building so simple that you are the only person working on it otherwise why is a ratio of 1:31 an effective ratio of collaboration for you? From my perspective, well functioning teams communicate with each frequently. What's the daily, short term (spring), long term plan? Why did that last plan go well/wrong and what should we do differently? Routine meetings have a habit of becoming rote, but it is difficult to ensure such conversations are spontaneously happening between more than a couple of people. I don't want my colleagues to be surprised when they review my implementation, so we need to discuss it before I do it and vice versa. Discussing those things ahead of times also allows us to plan and prioritize more effectively. It also helps us align and build a better understanding of what we are doing. I think people are obsessed with this kind of thing because people quest for a silver bullet, but individual teams working on disparate products and problems will find different strategies more effective and require a different balance of communication. Meanwhile, most organizations will push a chosen silver bullet in the name of consistency instead of enabling teams to truly self organize.

Xenoamorphous 2y ago
> What exactly does ideal team work look like to you? Certainly not something defined/constrained by the PM methodology du jour. I can and do reach my teammates frequently just like they do with me. This doesn’t preclude the occasional meeting or even the daily stand up, as I said. But in the end I want to know what I have to work on and who I have to reach if I need help or get blocked, and more importantly, be given the focus time to do it.
- skydhash 2y ago
  This. And I’ll be amenable to a team meeting to reflect and exchange on how the team have been doing. And even those demo meetings when a project got done. Or sharing knowledge and doing postmortems. I just don’t want the daily standups and the ritual retros. I never wait for these to share issues and provide updates.