7 ms·

I feel the exact same way. I come home and exercise and make food and I feel just beat. All I want to do is sleep by 9pm. I wish I had a few extra hours a day t

I feel the exact same way. I come home and exercise and make food and I feel just beat. All I want to do is sleep by 9pm. I wish I had a few extra hours a day to study or spend time on leisure activities. As it is I study or read until it's time to sleep and if I want to spend time with friends something has to fall off my schedule even though I sit at work and try to look busy most days. Once my work in a sprint is done my anxiety increases because now I don't know what to do and I'm considered lazy if I can't come up with some fascinating thing to produce. That's the most mentally draining aspect for me.

brixon 7y ago
As a Scrum Master the final comment bugs me. The Sprint is a team effort, you might have been assigned user stories, but if your velocity is higher than others then you need to improve your estimations and you need to help others finish their user stories. Your scrum team does not sound like a team, but a collection of individuals.
- ThalesX 7y ago
  So... what does the scrum master do then? If the developer needs to figure out how to work things out so he aligns with the rest of the team?
  - brixon 7y ago
    It depends. For me it's a 20% role, I focus more on the sprint flow. We have a System Engineer and they do most of the Product Owner cat wrangling that I would assume a lot of Scrum Master's have to handle. The scrum team should be acting as a team and the developer should work with the team to figure out how he aligns. That is part of the "Self Forming" stuff. The Scrum Master is not their boss and does not weigh in on the project implementation. They are more of the advocate for the team and the advocate for Agile/Scrum. e.g. Dealing with the Product Owner when they try to add stuff to the current sprint or Management saying everything is top priority. Technically we call that coaching the Scrum process, but I'm going to make sure my team has steady/predictable work and are not going to burn out.
- TheCoelacanth 7y ago
  This is exactly the attitude that causes anxiety. You are done with the thing you were working on, now go "help" one of your teammates somehow regardless of whether that will actually increase the amount of value the team is delivering. Baseball is a team sport, but that doesn't mean you have two people swinging one bat.
  - UglyToad 7y ago
    This is a nice metaphor. I think it's similar in many ways to the complaints one overhears about roadworks. "Why do they take so long!? It's just 5 people stood around watching another dig a hole!". Software is a lot like that, you can't have everyone run off and work on all parts of the stack and domain at once, there's only a certain amount of parallelizable work.
  - brixon 7y ago
    Examples are: The tester is always backed up (1 tester for 4 developers), so a developer can help test a user story they did not write. A developer can take on a user story that was originally assigned to someone else.
    - theprotocol 7y ago
      This is kind of a Kafkaesque way to destroy the developers' pysches. I feel like you've misunderstood the critical replies you've received above. You may think you are profiting by trying to allocate every millisecond of the developers' time, but it comes at a great cost that is hard to see upfront, but is very very real.
      - brixon 7y ago
        The sprint is two weeks long, if you finish your user stories in a week like OP, then is a full week of downtime ok? That will encourage everyone to sandbag the work to only need to work every other week. No one is talking about milliseconds or even hours, but I don't want the developers making up stuff to do like the OP mentioned or taking stuff off the backlog that the team did not agree to for the sprint. He used the word Sprint, so I assumed we were talking about a team and not just an individual, support your team, that's all.
- tonyarkles 7y ago
  “Fix your estimates” I have, for a long time, been very opposed to single point estimates, especially when those estimates are going to be interpreted like this. For any task that has any kind of uncertainty to it, there’s a range of time for how long it’s going to take. If you take longer than your single point estimate, you’re going to be punished for it in some way (work late, etc). If you take less time than your single point estimate, you’re going to be... punished for it? What I’ve settled on in my consultancy work is doing 3-point PERT-style estimates. If I finish a task earlier than the range that drops out, I make a mental note to be more optimistic in the future on that project. If I’m nearing the far end of the range, I take pause and reassess what happened. Did the scope of the task blow up? Did I miss something up front? Is there too much technical debt in this project? When you use SPEs, there’s no way to tell retrospectively (except in extreme cases) whether an estimate was actually good and the completion time was within an expected statistical variation, or if the estimate was bad and some part of the estimation process needs to be tuned.
  - brixon 7y ago
    I agree, I am assuming you know how we implemented Scrum.... We do point estimates very early to know if a story is too big and needs to be broken down and for rough release planning. The developer that volunteers for a user story will do an hours estimate when the user story is fairly well fleshed out. We do not use estimates and actual's for any management metrics, this is for the developer to gauge their workload for the sprint. We know from our history that once a developer estimates about 40 hours of work for a two week sprint we don't allow them to take any more. For us, estimates are the developers gauge to know when the sprint is full.
    - tonyarkles 7y ago
      > 40 hours of work for a two week sprint You're my hero. For real!
- malvosenior 7y ago
  As a senior engineering manager and individual contributor, your comment bugs me. You don't realize the value of "slack" and whitespace to allow people to perform at their best and most creative. If someone finishes their tasks early, let them breath and you'll have an amazingly happy, healthy and productive team member! Maybe they won't even quit 1 1/2 years into the job. Building a team and helping individuals grow is so much more than "maximizing" (not really) every minute of the work day.
  - simplemts 7y ago
    Just want to second your wonderful comment. Down-time is critical for productivity... it is not a paradox as one might seem. Just like exercising gives you MORE energy.
    - TheOtherHobbes 7y ago
      Down-time isn't down-time. Anyone who does any kind of mental work will continue thinking about the work even when they're away from their desk. They will think about it on the way to work. They will think about it during breaks. They will think about it while appearing to wander aimlessly around the building. They will think about it on the way home. They will think about it while they're at home, they will think about it in the shower, they will think about while eating or doing something else, and they will think about while they're asleep. It will take them at least two weeks of actual undistracted full-time down-time to stop thinking about it. But you can also make them stop thinking about it by piling on distractions - hiring sessions, meetings of all kinds, absolutely critical company events that aren't, and so on. And you can also make them stop thinking about it by giving them too much to do. Most people have enough mental space for one, maybe two, problem tracks. Giving them more - especially with limited context switching time - and you'll make it impossible for them to solve any of them. You're not running a physical production line. The typing and the code changes are the output of a complex and surprisingly fragile mental process. If you don't understand how the process works, you're wasting a lot of its potential value. Not only will people be unhappy, but the quality of their work will suck too.
- wbronitsky 7y ago
  The idea that I can add to the productivity of my team by inserting myself into other people's workstream is pretty thoroughly debunked. Not only would I be working out of context, I would force my coworkers to deal with that lack of context and compensate for it while I'm "helping" them. It also shoves my relatively higher productivity into my teammate's face, which is usually demoralizing. There are many other reasons that this reasoning is misguided, but I'll leave them for now and instead point you to those smarter and better written than I am. Luckily, there is a ton of writing on this. I'd start with "The Mythical Man Month" which explains that your reasoning is a fallacy with software engineering: https://archive.org/details/mythicalmanmonth00fred https://archive.org/details/mythicalmanmonth00fred

brixon 7y ago

As a Scrum Master the final comment bugs me. The Sprint is a team effort, you might have been assigned user stories, but if your velocity is higher than others then you need to improve your estimations and you need to help others finish their user stories. Your scrum team does not sound like a team, but a collection of individuals.

ThalesX 7y ago
So... what does the scrum master do then? If the developer needs to figure out how to work things out so he aligns with the rest of the team?
- brixon 7y ago
  It depends. For me it's a 20% role, I focus more on the sprint flow. We have a System Engineer and they do most of the Product Owner cat wrangling that I would assume a lot of Scrum Master's have to handle. The scrum team should be acting as a team and the developer should work with the team to figure out how he aligns. That is part of the "Self Forming" stuff. The Scrum Master is not their boss and does not weigh in on the project implementation. They are more of the advocate for the team and the advocate for Agile/Scrum. e.g. Dealing with the Product Owner when they try to add stuff to the current sprint or Management saying everything is top priority. Technically we call that coaching the Scrum process, but I'm going to make sure my team has steady/predictable work and are not going to burn out.
TheCoelacanth 7y ago
This is exactly the attitude that causes anxiety. You are done with the thing you were working on, now go "help" one of your teammates somehow regardless of whether that will actually increase the amount of value the team is delivering. Baseball is a team sport, but that doesn't mean you have two people swinging one bat.
- UglyToad 7y ago
  This is a nice metaphor. I think it's similar in many ways to the complaints one overhears about roadworks. "Why do they take so long!? It's just 5 people stood around watching another dig a hole!". Software is a lot like that, you can't have everyone run off and work on all parts of the stack and domain at once, there's only a certain amount of parallelizable work.
- brixon 7y ago
  Examples are: The tester is always backed up (1 tester for 4 developers), so a developer can help test a user story they did not write. A developer can take on a user story that was originally assigned to someone else.
  - theprotocol 7y ago
    This is kind of a Kafkaesque way to destroy the developers' pysches. I feel like you've misunderstood the critical replies you've received above. You may think you are profiting by trying to allocate every millisecond of the developers' time, but it comes at a great cost that is hard to see upfront, but is very very real.
    - brixon 7y ago
      The sprint is two weeks long, if you finish your user stories in a week like OP, then is a full week of downtime ok? That will encourage everyone to sandbag the work to only need to work every other week. No one is talking about milliseconds or even hours, but I don't want the developers making up stuff to do like the OP mentioned or taking stuff off the backlog that the team did not agree to for the sprint. He used the word Sprint, so I assumed we were talking about a team and not just an individual, support your team, that's all.
tonyarkles 7y ago
“Fix your estimates” I have, for a long time, been very opposed to single point estimates, especially when those estimates are going to be interpreted like this. For any task that has any kind of uncertainty to it, there’s a range of time for how long it’s going to take. If you take longer than your single point estimate, you’re going to be punished for it in some way (work late, etc). If you take less time than your single point estimate, you’re going to be... punished for it? What I’ve settled on in my consultancy work is doing 3-point PERT-style estimates. If I finish a task earlier than the range that drops out, I make a mental note to be more optimistic in the future on that project. If I’m nearing the far end of the range, I take pause and reassess what happened. Did the scope of the task blow up? Did I miss something up front? Is there too much technical debt in this project? When you use SPEs, there’s no way to tell retrospectively (except in extreme cases) whether an estimate was actually good and the completion time was within an expected statistical variation, or if the estimate was bad and some part of the estimation process needs to be tuned.
- brixon 7y ago
  I agree, I am assuming you know how we implemented Scrum.... We do point estimates very early to know if a story is too big and needs to be broken down and for rough release planning. The developer that volunteers for a user story will do an hours estimate when the user story is fairly well fleshed out. We do not use estimates and actual's for any management metrics, this is for the developer to gauge their workload for the sprint. We know from our history that once a developer estimates about 40 hours of work for a two week sprint we don't allow them to take any more. For us, estimates are the developers gauge to know when the sprint is full.
  - tonyarkles 7y ago
    > 40 hours of work for a two week sprint You're my hero. For real!
malvosenior 7y ago
As a senior engineering manager and individual contributor, your comment bugs me. You don't realize the value of "slack" and whitespace to allow people to perform at their best and most creative. If someone finishes their tasks early, let them breath and you'll have an amazingly happy, healthy and productive team member! Maybe they won't even quit 1 1/2 years into the job. Building a team and helping individuals grow is so much more than "maximizing" (not really) every minute of the work day.
- simplemts 7y ago
  Just want to second your wonderful comment. Down-time is critical for productivity... it is not a paradox as one might seem. Just like exercising gives you MORE energy.
  - TheOtherHobbes 7y ago
    Down-time isn't down-time. Anyone who does any kind of mental work will continue thinking about the work even when they're away from their desk. They will think about it on the way to work. They will think about it during breaks. They will think about it while appearing to wander aimlessly around the building. They will think about it on the way home. They will think about it while they're at home, they will think about it in the shower, they will think about while eating or doing something else, and they will think about while they're asleep. It will take them at least two weeks of actual undistracted full-time down-time to stop thinking about it. But you can also make them stop thinking about it by piling on distractions - hiring sessions, meetings of all kinds, absolutely critical company events that aren't, and so on. And you can also make them stop thinking about it by giving them too much to do. Most people have enough mental space for one, maybe two, problem tracks. Giving them more - especially with limited context switching time - and you'll make it impossible for them to solve any of them. You're not running a physical production line. The typing and the code changes are the output of a complex and surprisingly fragile mental process. If you don't understand how the process works, you're wasting a lot of its potential value. Not only will people be unhappy, but the quality of their work will suck too.
wbronitsky 7y ago
The idea that I can add to the productivity of my team by inserting myself into other people's workstream is pretty thoroughly debunked. Not only would I be working out of context, I would force my coworkers to deal with that lack of context and compensate for it while I'm "helping" them. It also shoves my relatively higher productivity into my teammate's face, which is usually demoralizing. There are many other reasons that this reasoning is misguided, but I'll leave them for now and instead point you to those smarter and better written than I am. Luckily, there is a ton of writing on this. I'd start with "The Mythical Man Month" which explains that your reasoning is a fallacy with software engineering: https://archive.org/details/mythicalmanmonth00fred https://archive.org/details/mythicalmanmonth00fred