Comment by klenwell | Hacker News Reader

Comment by klenwell | Hacker News Reader

Parent Full thread

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.

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.

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

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

>I'm mildly surprised WFH is lower.

Schools are closed.

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

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.

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

For a well-tuned, consistent team that has experience working together and estimating together,

do you have any other recommendation?

https://apenwarr.ca/log/20171213

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.

Yes, value velocity. It’s linked from the above blog entry.

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.)

This is where the right answer is "you do you", since only you and your team know what works best in your operating environment. The previous poster is correct, though, that working backward from business value measurements in order to drive IC behavior is almost always the smartest path.

Given this, I don't believe the this person's original argument is, to use their words, meaningful, then.

> Velocity isn't a productivity metric, so your findings probably aren't meaningful.

They were responding to someone that was using their average story point completion rate to track their productivity.

This person seems to be talking about what sorts of work to work on - the kind that makes the company money.

If it's already been predicted or measured that a certain project is going to earn the company money, then you need to know how long it's going to take to complete that project, which means either estimating it as a whole, or breaking the project into parts and estimating each part.

Assuming two projects of similar mathematical proportionality of size and value, you can then estimate velocity based on how much projected time it's going to take to complete each step of each project, as estimated by story points or similar.

In this way, story points can still be a meaningful metric that you can estimate velocity on.

In short, the discussion is on two separate things and their initial premise of velocity being meaningless is not correct.

There's a difference between productivity and prediction.

Velocity is a great prediction tool. Given a total estimate, it can tell you approximately how many weeks it will take to be done. It's a unit conversion factor: velocity = 25 points / week, therefore 100 points = 4 weeks.

Productivity is defined as output / input. Effort and time are both "input." Velocity is a way of converting from points (effort) to weeks (time). To measure productivity, you still need to define "output."

OP said, "On the productivity question, if you're interested in some soft (very squishy) numbers, I can provide them."

But OP didn't define "output," so they weren't measuring productivity. They just showed that their effort --> time unit conversion factor had changed. Given that there's any number of possible reasons for this—changes in hours worked, changes in overhead, changes in estimating technique, changes in estimate accuracy—the numbers probably aren't meaningful.

This still seems ancillary, though.

They're measuring how much work they're getting done based around approximate predicted complexity / work amount using story points and then using that to map overall work output and charting it from between non-WFH and WFH. If the projects they're working on have tended to remain of similar complexity with people that tend to be consistent, then this seems like a perfectly fine metric for exactly what they're trying to discuss: the relative output from WFH and non-WFH.

Yes, that’s fair. I would say that hadn’t measured a change in productivity, but rather a change in overhead, but that’s probably just me being nitpicky about the word “productivity.”

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?

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-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.

Reply on news.ycombinator.com