Hacker News Reader

Comment by zug_zug | Hacker News Reader

Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new.

The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).

You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.

View on HN

This. I moved from being the Main Tech Guy at a startup to being a backend engineer at a mature company running Scrum. I was amazed by how little work anyone did at the mature company. People obviously doing f-all during the day. If we finished our sprint 3 days early then we just pretended to be working (what is the point in having a standup every day when there are no tickets to work on?).

It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.

We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work.

Such a waste of time and talent.

> I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.

That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.

As a consultant with 25 years of experience in enterprise software for sizable corporations and universities, I have observed numerous development shops. The number of individuals in corporate America who accomplish little throughout the day is astonishing. This phenomenon aligns with the Pareto principle, wherein 20% of the workforce completes approximately 99% of the tasks and the rest are dead weight.

Our solution for this is to have nebulous time sucks that need to be done, but don't have a ticket with an estimate. Like "increase test coverage" or "experiment with new things for a git hook to do" or "eliminate warnings". There's no deadline, and everything else is higher priority- but when you finish your sprint early, now you know what you can work on. And it's useful, not just scutwork.

> Our team gets publicly dinged if we "carry over" tickets between sprints

This is not part of scrum

You'd be surprised at how many places this is.

At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint!

[0] Just writing that sentence makes my eye twitch

Similarly, in order to fit stories into a sprint and not spillover, there is the constant fixation on making stories "as small as possible". So now people make a story for adding a button, then another story for the click handler of the button, then another story for saving data into DB when button is clicked, then another story for adding the tests, and so on. Then the sheer amount of time talking about how to split that up and adding all those into JIRA...

It kind of is. Well, the public dinging probably isn't. But at a few companies I've seen, teams are tracked on how many tickets span multiple sprints. If it exceeds some threshold, then theoretically it means that either: 1. The team is not breaking down tasks granularly enough, or 2. They're not estimating tasks correctly

Practically, it means nothing of course.

In Scrum:

- the product owner sets the backlog priority

- team estimates

- team commits to what it can deliver from the backlog

- any misses are analyzed for scope mistakes

Rinse/repeat

There’s no shaming part

Edit: format

The scrum guide [1] says team gives a forecast and not a commitment. I have yet to know any other scrum practitioners aware of that update.

Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment.

The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment"

[1] https://www.scrum.org/resources/commitment-vs-forecast

*edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.

I can totally relate. We are not told not to do more work but at sprint planning if someone thinks a ticket would spill over then they should add it only to next sprint. So we do less work just to not spill over.

I had a team with a shadow backlog. Fun times

I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.

Great time to tackle some tech debt

Not if you can't work on anything without a ticket, and you can't add a ticket to the current sprint.

Do it anyway, file the ticket and pull it into the next sprint.

So stop following Scrum? Completely agree

Ah yeah I had a boss that wanted me to open tickets, estimate them, plan them, do them, to fix 1 line issues that I would randomly find working on other tasks.

Normally I just fix them within a separate commit.

Reply on news.ycombinator.com