5 ms·

On the productivity question, if you're interested in some soft (very squishy) numbers, I can provide them. I manage four small development teams and the one m

On the productivity question, if you're interested in some soft (very squishy) numbers, I can provide them. I manage four small development teams and the one metric I track is velocity or velocity per developer (VPD). If you're familiar with scrum, you probably have a sense of what this means. (Note: this data is tracked in an open spreadsheet and not used to reward or punish but rather to adjust and adapt.) Anyway, we went full-time remote from in-office 9-10 weeks ago. We did have some experience being partially remote (team members in different offices) before this. A comparison of avg VPD for last 3 sprints in-office (WFO) vs last 3 sprints (WFH): Team | WFO | WFH 1 | 8.6 | 7.8 2 | 9.2 | 7.6 3 | 8.1 | 7.6 4 | 7.5 | 7.7 This the first time I've actually compared them and I'm mildly surprised WFH is lower. Of course this ignores all sorts of caveats and qualifiers (like adjusting to a major change of environment and a pandemic!) My impression is that productivity has held more or less steady and VPD will eventually not be too different from where it was. I've also talked about this individually with members of my team. The consensus seems to be leaning toward a flexible mixture of WFH and WFO. That's the future I'd like to see.

prh8 6y ago
The fact that WFH under current circumstances is close to WFO under normal circumstances, I think that's vindication for WFH.
mapmap 6y ago
>I'm mildly surprised WFH is lower. Schools are closed.
- larrywright 6y ago
  And if you have kids but they aren’t yet in school, you’re likely juggling watching them while working.
dkn775 6y ago
One thing that stuck out to me is how consistent the numbers became between each other under WFH. I am not familiar with the metric or scrum, but I wonder what the cause is?
- klenwell 6y ago
  I noticed that, too. I think that's mostly coincidence. Velocity is based on story points. Here's a definition of story points as a unit of measure that I like: A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements. https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating https://www.scrum.org/resources/blog/why-do-we-use-story-poi... It is generally recommend you not include time as a component of that unit. For our teams, we kinda do. (Basically, for us, story point = time + uncertainty + complexity.) So there is a common standard. But with scrum you're supposed to size stories relative to other (previous) stories and I feel it's ok for the standard measure of a story point to drift apart between teams as long as its internally consistent to the team. So maybe there's some kind of leveling force at work. But probably not.
Redsquare 6y ago
Remember we are not robots, people are working under immense strain. I am very surprised at your mild surprise.
thebigspacefuck 6y ago
Any trend up or down on the past 3 months? Until lockdown, WFH for me meant coding on the couch. After lockdown, it took me some time to get a comfortable chair and ergonomics worked out. I'm still adapting, just ordered more office equipment that arrived on Sunday. When layoffs hit my company, that definitely made feel worried. Now that's over and I've been tuning out the news. I feel like I've been much more productive the past 2 weeks than when this started.
gilbetron 6y ago
VPD is a bullshit number easily game and highly prone to politics. I read this as "people in office have an advantage with politics". Which is a real thing. A bad thing, but a real thing. Suffocating Agile, as is the standard these days, is about pushing away risky, but really valuable tasks, in favor of fine grained, easily estimated and understandable tasks that are only of minor importance but "feel" like progress. They are more amenable to Bad Agile, and so are the tasks that get selected increasingly in the long run. WFH is far, far better at deep work, which is much more important to the long term value of a company.
jdlshore 6y ago
Velocity isn't a productivity metric, so your findings probably aren't meaningful. "Velocity is the sum of the estimates of the stories that were completed in an iteration. If the programmers estimate perfectly, it's simply a measure of the number of hours that the programmers worked, minus interruptions. The number is often confused by estimates that aren't 100% accurate. Velocity measures a strange combination of estimate accuracy and hours worked. It's a great planning tool, but as a metric, it has serious flaws." https://www.jamesshore.com/Blog/The-Productivity-Metric.html https://www.jamesshore.com/Blog/The-Productivity-Metric.html
- t-writescode 6y ago
  For a well-tuned, consistent team that has experience working together and estimating together, do you have any other recommendation?
  - xyzzy_plugh 6y ago
    https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213
    - t-writescode 6y ago
      Velocity is just the average sum of the story points a team completes The article you've provided continues to keep saying story points are good things. I don't know how we've found something contrary to what I've asked, yet.
  - jdlshore 6y ago
    Yes, value velocity. It’s linked from the above blog entry.
    - t-writescode 6y ago
      How do you measure: * multipliers, like infrastructure work or pipeline improvements? * fixing of technical debt that may have no immediate benefit? * projects of uncertain monetary value? * projects with great short term value but so much technical debt that they crumble the company a few years later? * moonshots that may revolutionize the company? How would organizations like the entirety of Microsoft Research where some guy got to play with coloring problems for a long time and that just so happened to end up requiring him to solve a subset of the halting problem, which just so happened to have benefit in driver validation? (It’s going to take me a looong time to find that source somewhere on the internet.)

prh8 6y ago

The fact that WFH under current circumstances is close to WFO under normal circumstances, I think that's vindication for WFH.

mapmap 6y ago

>I'm mildly surprised WFH is lower. Schools are closed.

larrywright 6y ago
And if you have kids but they aren’t yet in school, you’re likely juggling watching them while working.

dkn775 6y ago

One thing that stuck out to me is how consistent the numbers became between each other under WFH. I am not familiar with the metric or scrum, but I wonder what the cause is?

klenwell 6y ago
I noticed that, too. I think that's mostly coincidence. Velocity is based on story points. Here's a definition of story points as a unit of measure that I like: A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements. https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating https://www.scrum.org/resources/blog/why-do-we-use-story-poi... It is generally recommend you not include time as a component of that unit. For our teams, we kinda do. (Basically, for us, story point = time + uncertainty + complexity.) So there is a common standard. But with scrum you're supposed to size stories relative to other (previous) stories and I feel it's ok for the standard measure of a story point to drift apart between teams as long as its internally consistent to the team. So maybe there's some kind of leveling force at work. But probably not.

Redsquare 6y ago

Remember we are not robots, people are working under immense strain. I am very surprised at your mild surprise.

thebigspacefuck 6y ago

Any trend up or down on the past 3 months? Until lockdown, WFH for me meant coding on the couch. After lockdown, it took me some time to get a comfortable chair and ergonomics worked out. I'm still adapting, just ordered more office equipment that arrived on Sunday. When layoffs hit my company, that definitely made feel worried. Now that's over and I've been tuning out the news. I feel like I've been much more productive the past 2 weeks than when this started.

gilbetron 6y ago

VPD is a bullshit number easily game and highly prone to politics. I read this as "people in office have an advantage with politics". Which is a real thing. A bad thing, but a real thing. Suffocating Agile, as is the standard these days, is about pushing away risky, but really valuable tasks, in favor of fine grained, easily estimated and understandable tasks that are only of minor importance but "feel" like progress. They are more amenable to Bad Agile, and so are the tasks that get selected increasingly in the long run. WFH is far, far better at deep work, which is much more important to the long term value of a company.

jdlshore 6y ago

Velocity isn't a productivity metric, so your findings probably aren't meaningful. "Velocity is the sum of the estimates of the stories that were completed in an iteration. If the programmers estimate perfectly, it's simply a measure of the number of hours that the programmers worked, minus interruptions. The number is often confused by estimates that aren't 100% accurate. Velocity measures a strange combination of estimate accuracy and hours worked. It's a great planning tool, but as a metric, it has serious flaws." https://www.jamesshore.com/Blog/The-Productivity-Metric.html https://www.jamesshore.com/Blog/The-Productivity-Metric.html

t-writescode 6y ago
For a well-tuned, consistent team that has experience working together and estimating together, do you have any other recommendation?
- xyzzy_plugh 6y ago
  https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213
  - t-writescode 6y ago
    Velocity is just the average sum of the story points a team completes The article you've provided continues to keep saying story points are good things. I don't know how we've found something contrary to what I've asked, yet.
- jdlshore 6y ago
  Yes, value velocity. It’s linked from the above blog entry.
  - t-writescode 6y ago
    How do you measure: * multipliers, like infrastructure work or pipeline improvements? * fixing of technical debt that may have no immediate benefit? * projects of uncertain monetary value? * projects with great short term value but so much technical debt that they crumble the company a few years later? * moonshots that may revolutionize the company? How would organizations like the entirety of Microsoft Research where some guy got to play with coloring problems for a long time and that just so happened to end up requiring him to solve a subset of the halting problem, which just so happened to have benefit in driver validation? (It’s going to take me a looong time to find that source somewhere on the internet.)