Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you’re ever in a SAFe team, one of the tenants is that annual reviews are useless. It pushes for doing constructive reviews every PI (approximately quarterly).


On the other hand, you’re in a company doing SAFe so you have plenty of opportunity to stare at a wall.


But companies doing SAFe can use developer velocity to help judge individual dev productivity. That can be surprising if you aren't aware of what story points are used for.


As someone who is again at a company doing SAFe, I am genuinely curious as to the relevance of story points.

For estimation, hours is a good measure, even more so when there are external consultants that get paid by the hour.

Developer velocity can be measured by tasks/features completed compared to the estimate.

Could you elaborate on why story points are useful or perhaps point to some resources on the topic ?


I'm not saying it's useful, just that I found out it was a metric for management. I was originally expecting it to be an internal metric. The company I was at actually used it in performance reviews somewhat comparable to stack ranking.

There was an expectation that devs complete about 8 points a sprint. I don't know if the eight point target is common, but SAFe does talk about comparing story points across teams.

> At scale, it becomes difficult to predict the story point size for larger epics and features when team velocities can vary wildly. To overcome this, SAFe teams initially calibrate a starting story point baseline where one story point is defined roughly the same across all teams.

...

> Give every developer-tester on the team eight points for a two-week iteration

https://www.scaledagileframework.com/story/


This is a hot button for me also. Story points are a solid measure of complexity, but when it comes to estimates on a planned timeline over the next few weeks I want it in hours or days.

Otherwise, somebody ends up trying to convert story points into hours and that's not what it's there to measure.

I wrote extensively about this a couple of years ago before I found out about SAFe itself.

https://www.brightball.com/articles/reality-driven-developme...


If I'm ever again in a SAFe team, something has gone terribly wrong. I won't join a company that uses this practice unless I'm very desperate. If a company I'm at adopts it after I've joined I will immediately begin looking elsewhere.


Yea, I'm very curious to hear more about this.

I've loved it at my company. It seems like development best practices + sanity enforcement outside of it and it's fairly flexible too (we use kanban instead of scrum).

It's done wonders for putting the planning of how things should be implemented into the hands of developers themselves and then essentially gets out of the way.


Why? reading Wikipedia this seems to be what used to be called RAD - done right its Fucking awesome.

One thing is you need 100% collocated experienced people who know what they are doing - no third party agencies who spend 15 mins discussing pixel separation in photoshop mock-ups.

It also not something you'd carelessly throw a junior or an intern into


SAFe as I’ve seen and experienced it is a cumbersome, process-heavy system. Like most other project management systems currently in use in this industry it’s probably okay if 95% or more of the features are well-known and specified clearly. For any non-trivial software development work it’s a burden. For development touching other disciplines (e.g. statistics/ML, new product development) it’s more like an obstacle.


It is process heavy outside of the dev flow, but that is more business side so it shouldn’t affect devs themselves much.

It’s supposed to be getting out of the way of developers.


I've never been on a SAFe team so maybe this is addressed in that methodology, but I think annual reviews are more a tool to pass your performance up to higher levels in a structured manner as opposed to letting you or your boss know how you're doing. Like the GP said, the manager and their direct typically know exactly how they're doing, or at least more or less where they fall on the spectrum of the team. Ideally stand ups should give daily feedback to everyone when someone starts to fall behind, and managers should be giving their directs feedback often (not necessarily daily).


Yes, exactly this. What I tell my directs when they write their reviews is two things. The lesser one is that I'm a human and I don't remember all the awesome stuff that everyone does through a whole year. So now is the chance to remind me of it.

Secondly, and more relevantly and importantly, I'm about to walk into a shooting match to defend my employees' performances against a larger pool. And what I need in that battle are bullets. The more bullets I have, the more successful I will be. So load up my gun with every single bullet you can think of!


Do you make an effort throughout the year to write down all the awesome stuff your directs have done?


During our one-on-ones I try to take notes. But I still miss things. Visibility is always a problem, and is even more binary now with remote working. I have zero chance to stumble into awesome things happening. I can either already see it happening or I can't.


Sorry but what is SAFe? (No pun intended)


Scaled Agile Framework https://www.scaledagile.com/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: