Comment by dragonwriter | Hacker News Reader

Comment by dragonwriter | Hacker News Reader

Parent Full thread

> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room

It is central to the idea of the daily standup is that it is one team.

> Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board.

If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for sharing information about and resolving barriers.

> Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments.

If you organizationally can't get away from commitments, then you need to cut back the amount you plan to do so that there is some slack. As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly.

> As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly.

The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predictability goes down. Thus, we are encouraged to not take on extra work if we don’t expect to finish. What this means in reality is that we start working on it without pulling it into the sprint and then get a head start for next sprint.

What’s your take on that?

My (related) experience has led me to believe reporting to management should be strictly separate from any tools or processes used to track actual work, specifically to avoid dumb shit like this. Team task-tracking should be a team communication tool. If you want to report task-related stuff upstream it should be totally separate, with updates/sync done by a human (project manager would make sense).

I also think speculative future make-believe planning junk should be kept out of the real getting-shit-done tool. Put it in there when it actually matters. There should be no "on ice" or "phase 3" (when in "phase 1") crap in the tool the devs use. It may or may not make sense to have them involved in planning stuff that early, but keep the output of that planning away from the real-work trackers until it's closer to time to do it.

I think that's part of why Jira (and similar, heavy, report-focused tools) is so god-awful. It not only tries to have features for teams to get stuff done and for five other roles to dig around in tasks and reports for whatever reason, it enables and encourages that, and I'm fairly sure, at this point, that it's fundamentally a bad idea.

> My (related) experience has led me to believe reporting to management should be strictly separate from any tools or processes used to track actual work,

This probably increases the accuracy of the work trackers but increases the B.S. level of management reporting in organizations where there are fundamental problems between management and the working level.(Which is the only reason anyone would want to separate these two things.)

While this probably seems like an improvement from the working level, it's probably bad for the organization. The solution is not dis-integrating communication tools so that management's view is not connected to the actual work tracking, but dealing with the fundamental trust issues. Which is hard, of course, but things that are important often are.

I get why they want it, but I think it's a case of false improvements from adding more computers. If the reports to management are such BS that they don't usefully resemble reality they should be able to figure that out before long and sort things out, one way or another. If they want insight into the tools the bottom-of-the-ladder workers are using to coordinate then that coordination will suffer, greatly, and those tools themselves will be full of BS, for sure, gaining little aside from some pretty "real-time" BS graphs for management and worse communication for workers.

[EDIT] more to the point, I think if it worked we wouldn't still constantly see management surprised when things aren't delivered "on time", and yet, that still happens all the time. IMO the team needs someone "on their side" to report reality upwards, diplomatically, not their own work tools reporting up directly, or they'll lie to their tools, which leads to more surprises, not fewer.

There's certainly environments where that makes a lot of sense, particularly where the software at issue had immediate effects on external users who require advance notice of changes (I actually work in that kind of environment, and though we do have opportunistic items they generally are restricted to items that don't impact external users.)

What answer are you expecting? Your example indeed makes no sense, but it has nothing do with scrum and has everything to do with clueless people do stupid things. Do you expect this guy will suddenly do only sane logical things when using something other than scrum? I expect not.

If you're trying to do scrum properly, you shouldn't be consistently finishing work early. That implies you're overestimating stories.

When you do finish a bit early I've not normally found it a problem to find some small bits of tech debt, research, or admin work to fit in before the end of the sprint.

Starting work on stuff from the next sprint is not ideal because it'll throw your estimates off for the next sprint, plus you don't actually know for sure what is going into the next sprint.

Reply on news.ycombinator.com