7 ms·

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'

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?"

tbrock 7y ago
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.
- hrktb 7y ago
  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 ?
- skgoa 7y ago
  And if you don't use the tools the way they are meant to, you are just wasting massive amounts of time.
- systemtest 7y ago
  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.
  - verinus 7y ago
    this is so anti-agile but well...if management does not understand how developing software works what can you do...
  - perlgeek 7y ago
    > 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.
- camgunz 7y ago
  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.
dfischer 7y ago
Exactly this. Enable peer collaboration, enable the team to talk to each other as needed, don't force meeting time.
ryandrake 7y ago
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.
- repolfx 7y ago
  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).
  - ryandrake 7y ago
    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.
mnm1 7y ago
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.
- mixmastamyk 7y ago
  I worked at a place like that ten years ago. Worst dev job I ever had.
navyad 7y ago
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.

tbrock 7y ago

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.

hrktb 7y ago
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 ?
skgoa 7y ago
And if you don't use the tools the way they are meant to, you are just wasting massive amounts of time.
systemtest 7y ago
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.
- verinus 7y ago
  this is so anti-agile but well...if management does not understand how developing software works what can you do...
- perlgeek 7y ago
  > 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.
camgunz 7y ago
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.

dfischer 7y ago

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

ryandrake 7y ago

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.

repolfx 7y ago
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).
- ryandrake 7y ago
  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.

mnm1 7y ago

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.

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

navyad 7y ago

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.