Hacker News Reader

Comment by icedchai | Hacker News Reader

I worked at a place that ran sham sprints all the time. If you couldn’t finish something, your ticket would get marked complete, and a new one opened to finish the work (“integrate [component]”) next sprint. This was so the points would be booked and the team stats wouldn’t look bad. I saw one ticket roll over for a good 2 or 3 months like this.

View on HN

Sprints are bullshit, so people use this method to work around this. It's actually kanban implemented over Scrum.

It's just too common for a task to turn into an "epic" mid-sprint. I only see value in sprints as regular checkpoints but the expectation that all tasks are finished after 2 weeks is just contrary to reality of software development in large organisations.

What are you talking about is problem that you are committing to to much in sprint, thus, your velocity is inaccurate. If I can give you a piece of advice: not finished items should be marked as 0 work done and moved to next sprint, and thus it will affect your team's velocity in future sprints making you commit to less items, which should result in that eventually you will have real velocity of the team and you will know how much work you can complete in each iteration. Of course opposite is also true - with time you can get knowledge or improve codebase in such way that your velocity will go up.

I agree with you, but the "scrum masters" did not want to do that, as it would not "properly account" (their words) for any work done. There was a head bean counter that actually believed the numbers, and would count up all the points and track the completed vs planned. It would cause our stats to look bad if we achieved less work completed. Personally, I did not care about stats, I would rather improve our estimation process. I thought the whole thing was a gamified sham and left.

In my professional experience as developer I'm terribly disappointed with so called "scrum masters" dedicated for the job, the teams that I worked in that implemented scrum correctly were the teams where the team itself took the responsibility to do it right on themselves.

...and we come back to one of agile principles: "the best architectures, requirements, and designs emerge from self-organizing teams". I think the scrum itself says to not confuse the job title with the role and I believe that's what happening in many cases. But it all looks good on paper, we have scrum because we hired scrum master so management is happy whereas in reality it is not true - I saw it many times.

The scrum master on one of my teams literally did nothing. He phoned it in from his kid's basketball games, and tried pushing his responsibilities onto someone else. It was laughable how little work this guy did. He was one contribution was asking if we could break a 5 point ticket into smaller ones.

So, arguably, you are not mad at scrum, you are mad at people who lied to you that you were doing scrum.

Reply on news.ycombinator.com