5 ms·

OK, this is actually a really good and insightful article hidden behind a provocative title. I will say that “velocity” is an extremely helpful concept at the

OK, this is actually a really good and insightful article hidden behind a provocative title. I will say that “velocity” is an extremely helpful concept at the level of the individual and small teams. With my trams I challenge each engineer to try and batch work into 2-4 hour chunks, with each chunk being labeled “1 point.” Thus if we have an ideal week there are theoretically 10 points of “velocity.” We also try to batch up meetings etc. and discount the coordination overhead from the plausible output, so maybe the theoretical ideal is lowered to 8-9 points. We all discuss and agree on that based on whatever overhead we can’t eliminate. Then each engineer does their best to “call their shot” every week and say how much work they’ll finish. At the end of the week we compare their prediction against reality, using a burn-up chart as a visual aid to the flow of work. There’s no penalty for getting it wrong, just applause for nailing it, and always a discussion of what worked and what could have gone better. Following this habit, I have consistently seen teams get much better at forecasting work into the future accurately. This ability to have a steady velocity and make reasonably accurate forecasts about how long things may take is extremely valuable and helps us align and coordinate efforts across many teams.

q7xvh97o2pDhNrh 4y ago
I'm generally extremely allergic to time-based micro-estimation like this, but it sounds like you've got the rare healthy implementation of it. (Or as healthy as it can get, at least.) Two questions, if you don't mind: 1. One of the biggest dangers of time-based estimation is the cultural danger around the "penalty for getting it wrong." It's got quite a lot of gravity to it, in my experience. Once there are time-based estimates for tiny bite-sized amounts of work, it's a hop-skip-jump to the toxicity of "holding people accountable for their commitments." It sounds like you, as the team manager, are the one preventing this backslide. How do you think about maintaining a healthy culture around this when you go on vacation, get distracted, get promoted, etc? 2. What if a new discovery happens mid-week? Specifically, what if it's the kind of discovery that invalidates the current plan, so that finishing your "committed" work would be worthless (or actively negative) for the business?
- switchbak 4y ago
  I echo your concerns. On teams I've been on (exclusively at large, boring organizations), I've seen a tendency to create lots of really trivial tasks, and also to game things via pretending these tasks are more complex than they are. It's easy to nail your estimations when you're operating at 1/3 your capacity, and you only ever meet but don't exceed the planned velocity. I wonder if this also disincentives learning and innovation in the solution domain - because that would throw off all those estimates.
  - burlesona 4y ago
    This is addressed by batching into same-sized chunks - the engineers discuss the work plan as a group and if you give yourself ten tickets that everyone knows are tiny and should probably be done in an afternoon, the group will ask you to group it into a parent ticket to make it a "half-day" chunk of work.
    - switchbak 4y ago
      Not when the entire team is in on the charade. Or enough are in on it such that they bloat sizes unreasonably. Also what you describe sounds... Like something I wouldn't want to be a part of. Breaking down smaller stories only to fold them into a bigger one?
  - peteradio 4y ago
    Thus is born the emergent 10xer, one who was once normal rises as cream above the moral decay.
- burlesona 4y ago
  (1) This is part of blameless culture, and it can't work without everyone being bought in, so once it is established and working culturally it doesn't matter if one person on the team changes. In the same way that we "hold people accountable for incidents" by reviewing them and discussing what we could learn, we do "hold people accountable for their estimates" by asking what happened and reflecting on whether we could have seen that coming. But we're never perfect and we don't expect to be, we just try to see if we can get better over time. (2) When something unexpected comes in you flag it and report it to everyone so everyone knows the expectations are invalidated. This is super important! I can't even tell you how much easier it is for a PM or other stakeholder to handle learning on Tuesday that the plan is not going to work than showing up for a check-in the next Monday expecting to see some deliverable and only then learning that it's late. The goal is to communicate expectation changes as close to real-time as possible, which builds trust and also helps the non developers see how volatile and unpredictable development can be so they learn to believe you when you say "the range is 10 to 30 weeks, and no I can't narrow it down any more than that."
welshwelsh 4y ago
A 2-4 hour chunk of work is 1 day of work. By that measure, ideally each engineer would hit 5 points per week. Managers like to think, if an engineer can do 1 point in 4 hours, then they should be able to do 2 points in 8 hours. But that's not how it works. The average office worker is only productive for about [3 hours a day](https://www.vouchercloud.com/resources/office-worker-productivity https://www.vouchercloud.com/resources/office-worker-product...). The upper bound is [4-5 hours a day](https://www.washingtonpost.com/lifestyle/wellness/productivity-focus-work-tips/2021/05/31/07453934-bfd0-11eb-b26e-53663e6be6ff_story.html https://www.washingtonpost.com/lifestyle/wellness/productivi...). More than that is unsustainable and leads to burnout. This is why people prefer remote work. Seeing coworkers in person is nice, for sure. But management still assumes people work 8 hours a day, meaning office workers spend most of their day trapped in the office pretending to work, which is a huge waste of time.
- burlesona 4y ago
  I've found this isn't true for myself and for many others. If you are getting good, deep focus time then you can generally get one productive stretch in the morning, take a good long break, and then do one more productive stretch in the afternoon. We can be pedantic about it and say "well the sum total of truly deep focus time was probably not more than 4-5 hours" and that may be true, but it's also not a realistic take on the context switching and ramp up time that it takes to get into that flow in the first place. Also don't underestimate how many shallow tasks there are that somebody has to do to keep the lights on. We try and eliminate as many of these as we can, but it's just not cost effective to eliminate the entire long tail. So it's pretty common to have the morning focus session be true "deep work," and the afternoon session be a batch of minor stuff like small bug fixes, updating dependencies, running some tests, etc.
  - zmgsabst 4y ago
    In my experience, the breakdown is something like: - 3-4 hours of deep work - 1-2 hours communication, in the form of meetings, emails, writing wikis, etc - 1-2 hours teamwork, like CRs, impromptu whiteboarding, pair programming, etc - 1 hour misc, like coffee breaks, bathroom breaks, walking between meetings, etc I think a lot of managers fail to account for everything else employees have to do, so “four hours of deep work per day” doesn’t sound right… even if it is. Of course, a lot of managers also just push their team into working more than 8 hours per day.
twic 4y ago
This sounds sensible and effective, and fairly similar to experience on effective XP teams. Two things are different to the XP approach. Firstly, you track expected work capacity at the level of individuals, rather than the whole team. Secondly, you use estimates of work capacity, rather than the "yesterday's weather" approach of assuming it will be the same as last week. Do you think there are advantages to doing it your way?
- burlesona 4y ago
  Sorry if I wasn't clear, in the method I'm describing each engineer is tracking and forecasting their own capacity one week at a time. We discuss it briefly as a team to gut-check each other's forecasts and learn from misses as a group. Misses are almost always unexpected interrupts, so talking about what did we fail to see last week and then checking what might we be missing in the plan for this week is the essence of the whole thing. Having never done XP I can't say if the differences are better, I can only say that this basic approach works pretty well :)

q7xvh97o2pDhNrh 4y ago

I'm generally extremely allergic to time-based micro-estimation like this, but it sounds like you've got the rare healthy implementation of it. (Or as healthy as it can get, at least.) Two questions, if you don't mind: 1. One of the biggest dangers of time-based estimation is the cultural danger around the "penalty for getting it wrong." It's got quite a lot of gravity to it, in my experience. Once there are time-based estimates for tiny bite-sized amounts of work, it's a hop-skip-jump to the toxicity of "holding people accountable for their commitments." It sounds like you, as the team manager, are the one preventing this backslide. How do you think about maintaining a healthy culture around this when you go on vacation, get distracted, get promoted, etc? 2. What if a new discovery happens mid-week? Specifically, what if it's the kind of discovery that invalidates the current plan, so that finishing your "committed" work would be worthless (or actively negative) for the business?

switchbak 4y ago
I echo your concerns. On teams I've been on (exclusively at large, boring organizations), I've seen a tendency to create lots of really trivial tasks, and also to game things via pretending these tasks are more complex than they are. It's easy to nail your estimations when you're operating at 1/3 your capacity, and you only ever meet but don't exceed the planned velocity. I wonder if this also disincentives learning and innovation in the solution domain - because that would throw off all those estimates.
- burlesona 4y ago
  This is addressed by batching into same-sized chunks - the engineers discuss the work plan as a group and if you give yourself ten tickets that everyone knows are tiny and should probably be done in an afternoon, the group will ask you to group it into a parent ticket to make it a "half-day" chunk of work.
  - switchbak 4y ago
    Not when the entire team is in on the charade. Or enough are in on it such that they bloat sizes unreasonably. Also what you describe sounds... Like something I wouldn't want to be a part of. Breaking down smaller stories only to fold them into a bigger one?
- peteradio 4y ago
  Thus is born the emergent 10xer, one who was once normal rises as cream above the moral decay.
burlesona 4y ago
(1) This is part of blameless culture, and it can't work without everyone being bought in, so once it is established and working culturally it doesn't matter if one person on the team changes. In the same way that we "hold people accountable for incidents" by reviewing them and discussing what we could learn, we do "hold people accountable for their estimates" by asking what happened and reflecting on whether we could have seen that coming. But we're never perfect and we don't expect to be, we just try to see if we can get better over time. (2) When something unexpected comes in you flag it and report it to everyone so everyone knows the expectations are invalidated. This is super important! I can't even tell you how much easier it is for a PM or other stakeholder to handle learning on Tuesday that the plan is not going to work than showing up for a check-in the next Monday expecting to see some deliverable and only then learning that it's late. The goal is to communicate expectation changes as close to real-time as possible, which builds trust and also helps the non developers see how volatile and unpredictable development can be so they learn to believe you when you say "the range is 10 to 30 weeks, and no I can't narrow it down any more than that."

welshwelsh 4y ago

A 2-4 hour chunk of work is 1 day of work. By that measure, ideally each engineer would hit 5 points per week. Managers like to think, if an engineer can do 1 point in 4 hours, then they should be able to do 2 points in 8 hours. But that's not how it works. The average office worker is only productive for about [3 hours a day](https://www.vouchercloud.com/resources/office-worker-productivity https://www.vouchercloud.com/resources/office-worker-product...). The upper bound is [4-5 hours a day](https://www.washingtonpost.com/lifestyle/wellness/productivity-focus-work-tips/2021/05/31/07453934-bfd0-11eb-b26e-53663e6be6ff_story.html https://www.washingtonpost.com/lifestyle/wellness/productivi...). More than that is unsustainable and leads to burnout. This is why people prefer remote work. Seeing coworkers in person is nice, for sure. But management still assumes people work 8 hours a day, meaning office workers spend most of their day trapped in the office pretending to work, which is a huge waste of time.

burlesona 4y ago
I've found this isn't true for myself and for many others. If you are getting good, deep focus time then you can generally get one productive stretch in the morning, take a good long break, and then do one more productive stretch in the afternoon. We can be pedantic about it and say "well the sum total of truly deep focus time was probably not more than 4-5 hours" and that may be true, but it's also not a realistic take on the context switching and ramp up time that it takes to get into that flow in the first place. Also don't underestimate how many shallow tasks there are that somebody has to do to keep the lights on. We try and eliminate as many of these as we can, but it's just not cost effective to eliminate the entire long tail. So it's pretty common to have the morning focus session be true "deep work," and the afternoon session be a batch of minor stuff like small bug fixes, updating dependencies, running some tests, etc.
- zmgsabst 4y ago
  In my experience, the breakdown is something like: - 3-4 hours of deep work - 1-2 hours communication, in the form of meetings, emails, writing wikis, etc - 1-2 hours teamwork, like CRs, impromptu whiteboarding, pair programming, etc - 1 hour misc, like coffee breaks, bathroom breaks, walking between meetings, etc I think a lot of managers fail to account for everything else employees have to do, so “four hours of deep work per day” doesn’t sound right… even if it is. Of course, a lot of managers also just push their team into working more than 8 hours per day.

twic 4y ago

This sounds sensible and effective, and fairly similar to experience on effective XP teams. Two things are different to the XP approach. Firstly, you track expected work capacity at the level of individuals, rather than the whole team. Secondly, you use estimates of work capacity, rather than the "yesterday's weather" approach of assuming it will be the same as last week. Do you think there are advantages to doing it your way?

burlesona 4y ago
Sorry if I wasn't clear, in the method I'm describing each engineer is tracking and forecasting their own capacity one week at a time. We discuss it briefly as a team to gut-check each other's forecasts and learn from misses as a group. Misses are almost always unexpected interrupts, so talking about what did we fail to see last week and then checking what might we be missing in the plan for this week is the essence of the whole thing. Having never done XP I can't say if the differences are better, I can only say that this basic approach works pretty well :)