Hacker News new | past | comments | ask | show | jobs | submit login

My conclusion is there are 2 kinds of engineer: good ones and shit ones.

Good ones just need to be told what to do and be left to get on with it. They value autonomy, and any attempt to micromanage them with agile bullshit drastically demotivates them.

Shit ones are shit. They need a good one to help them get through their tickets, by asking what's taking so long and showing them better ways of approaching the problem. They need more handholding and don't yet find ticket-sizing a soul-sucking waste of time.

Shit ones might become good ones over time, or they might not.

The problem is that scrum masters are either former shit engineers or non- technical, so cling dearly to the belief they add some value to the process by acting like a parent (which only benefits the shit ones) or sizing things which benefits no one as it takes too long and is too inaccurate to be useful. Worse, it just demotivates good engineers.

Instead, teams need a mix of good and shit engineers, quick standups whose purpose is for the good engineers to realise shit ones need help, and very high level rough estimates at the project level of "this'll probably take us about 3 months". Then get out of their way but be there if they have a blocker.

Good engineers will tell you they need help, they don't need a frigging question every morning as if they're 5.




As someone who pulled part-time scrum master duties in a seed stage startup, the problem is that engineers, even good ones, tend to be not-so-great communicators. Having someone to grease the wheels in stand ups and planning meetings decreases the time it takes for issues to surface. The other half of the job is cleaning the backlog and keeping the product owner from derailing development. It’s more about waste reduction than adding value.

Granted this was just my very limited experience, and we didn’t spend much time on estimating and standups consisted of a scheduled daily Slack ping instead of a meeting since we had major timezone offsets. People over process and all that.


Not only that. Agile processes in general are supposed to protect everyone from sinking a tonne of effort into successfully building the wrong thing. It doesn't matter if people aren't going as fast as they otherwise might, if the counterfactual has them going in completely the wrong direction.

Scrum itself is more specifically designed to protect the team from management interference. Engineers might think it's a waste of time preventing them from getting things done, but in its absence (where it's truly needed) what would actually be happening is constant micromanagement, context switching, and death-march deadline pressure. In its originally-intended form it's not an arbitrary collection of hand-holding niceties, it's a self-defence measure.


I don't agree with the tone, but there's some truth here.

A good SM or delivery lead can make a huge difference. Good management is very impactful too. So we should add as much of that as possible.

That last part is obviously absurdly wrong, but it is easy to see the pathway that gets people there.


I wish I could spend karma to upvote this more.


That would be a really interesting HN feature. You can upvote once, and it's free. But if you really feel strongly, you can upvote more, but each additional upvote costs you a karma point.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: