Hacker News Reader

Comment by ravenstine | Hacker News Reader

You know what I don't get about status updates? We're all using tools like Jira, Trello, Pivotal Tracker, GitHub issues, etc., where you can see what everyone's working on and the status of each of those tasks. Why do we need frequent status updates like standups and PMs looking over our shoulders if you can just go to the project board and look for yourself? If I'm going to be asked about the status of what I'm doing every day, then don't make me use these systems.

It's like that episode of Seinfeld where Kramer pretends to be Moviefone. "To update the status of your ticket, press 1 now. .......... Why don't you just tell me the status of your ticket?"

View on HN

They are purely for management to feel like they useful and making a contribution when they mostly aren't. And with the stand-up/scrum mindset we get to waste everyone else's time too. I don't have a single example where another developer's stand-up update was useful to me. I don't even pay attention. I almost never know what I'm actually going to be working on at the beginning of the day so I just guess. That too is management's fault as they shift priorities constantly. The whole status update meeting is a waste of time. And it's not five minutes anymore it's thirty to forty five destroying peak concentration time in the morning. Because they are so early, I usually finish early and lose the peak concentration time in the evening instead of sleeping late and focusing on work at peak times. Then managers wonder why things take so long when they destroy every morning and every evening of work. When you treat and mistreat people like robots, you get shitty work. Yet management is oblivious and trying to change or even communicate this to them falls on deaf ears. Well they reap what they sow and it's a shit crop.

I worked at a place like that ten years ago. Worst dev job I ever had.

Your team needs excellent JIRA hygiene for that to actually work. I’ve been on and managed teams where it’s expected and demanded and others where it was an afterthought.

Our JIRA board is being gamed for management. Our sprint burndown chart always looked terrible because management changed things around mid-sprint by adding issues or swapping them around. So we have a fake JIRA board that has a perfect linear downwards progression because we keep changing the story points.

For actually tracking the progression of the sprint we have a secret Slack channel that management can't see.

This way we don't have to explain to a spreadsheet monkey why the burndown chart looks like a skyline.

> Our JIRA board is being gamed for management. Our sprint burndown chart always looked terrible because management changed things around mid-sprint by adding issues or swapping them around. So we have a fake JIRA board that has a perfect linear downwards progression because we keep changing the story points.

This makes me so sad.

The jagged burndown chart should be the perfect tool to explain management that you didn't finish the sprint BECAUSE MANAGEMENT CHANGED OR ADDED THINGS, and so visualize the cost of such actions.

this is so anti-agile but well...if management does not understand how developing software works what can you do...

I think parent’s point stands: if JIRA is hard and requires excellent discipline, why bother in the firth place, and why not go with a rougher board and the micro status checks only ?

Yeah but tools almost always provide automation hooks. You can configure status to update on branch creation, PR creation, merge, deploy, etc. Always be automating.

And if you don't use the tools the way they are meant to, you are just wasting massive amounts of time.

Great point. The tools are there to make life easy for developers. Even after using these tools, PM need to do checkins with team then I think something is very wrong in terms how PM is handling the team.

Exactly this. Enable peer collaboration, enable the team to talk to each other as needed, don't force meeting time.

I'm a big believer in "using the tools engineering is already using" but you need to also have a culture of including status updates in bugs. Developers typically are used to putting developery stuff in bugs, not statusy stuff. Crash logs, stack traces, commentary on possible root causes, diffs, etc. you can always find in the bug history. But updates? Not so much. Even a little "UPDATE: Root cause found, fix in progress, ETA 2 days," which takes 10 seconds to write, would make your Project Manager love you and stop him/her from inadvertently interrupting you out of the zone.

Developers don't want to give you ETAs, especially not for bug fixes where 90% of the time they have no idea how long it's going to take. I've never seen developers volunteer such estimates - they always have to be demanded (and are often wrong, hence the reluctance).

I agree.. it’s not something that comes naturally. Encouraging this kind of culture/discipline is hard, but worthwhile. I think it’s better than the alternative of getting hounded by PMs all day. Like it or not, estimation, deadlines and status updates are part of any commercial engineering endeavor. I’ve never worked at a place where “It’ll be done when it's done” is the way.

Reply on news.ycombinator.com