Hacker News Reader

Comment by commandlinefan | Hacker News Reader

I've had great bosses, all the way up the chain... but they were all held captive to the "efficiency" measures of the time-tracking system. Everywhere I've ever worked has implemented a methodology that, regardless of what they called it (XP, Scrum, Kanban, whatever) boiled down to: write down everything you're going to do, write down how long it's going to take, and I'm going to measure how accurately you predicted how long it was going to take. And then they start clamping down on the "what you're going to do" part and make sure that everything you're "going to do" aligns with the business goals (that is, has a direct, immediate path to more money). Obviously reading an entire book would never fly under this regime.

It's doubly frustrating because it's always there, and drives so much inefficiency _in the name of_ efficiency.

View on HN

> but they were all held captive to the "efficiency" measures of the time-tracking system

Were you working at an agency or consultancy that billed hours to clients?

I've never seen a good engineering organization use time tracking software on their engineers.

I'd go so far as to take it as a major negative sign against the company if your time is being tracked like that. Exceptions of course to any business that is billing hours, which obviously must be tracked. However, even those organizations are smart enough to know that writing code isn't the only productive activity.

Not parent poster but I've seen more and more startups setting up their jiras with whatever the folks who invented "safe" (scaled agile framework) say, while obsessing over measuring and predicting delivery metrics, all in order to have hard data to backup roadmap claims.

You're performing a local optimization rather than a global one. The reason predictability of delivery matters is that the rest of the company needs to do a bunch of work for the set of features you're delivering. Support needs training, marketing needs to send some emails, the sales team needs to update their demos, etc.

For what it's worth, I've been doing this for 10+ years, being a lead, a manager, and I never worked anywhere that tried to have "efficiency" measurements of devs.

Agreed. Agile needs to be for developers first and foremost, not the management.

At least, in Scrum, from my experience so far: pointing is about measuring the uncertainty to delivery, but should healthily include learning, tech debt refactors,testing, q/a, even unexpected stuff like dev churn (i.e shoot under always, over estimate slightly).

But if individual performance is measured by velocity and points, you will just get devs badly cutting corners and gaming it while project & product will never get accurate measurements they can tie time based business outcomes to (especially as you get further out and short term corner cutting starts to rear it's head as brutal Tech Debt and time sinks)

Reply on news.ycombinator.com