Hacker News Reader

Comment by jyriand | Hacker News Reader

What i don’t like most about scrum is the sprints. Doesn’t matter if it’s one or two weeks long, we never have a successful sprint, the velocity chart looks like random numbers, and we spend hours on debating what the story points really mean. Sprints are artificial deadlines that don’t really make any sense, developers don’t care, business people don’t care. A project i could complete in a month will take at least three months, because of the processes we have to follow. Instead of refactoring and thinking about overall design i have to worry about getting the task done by the end of the sprint.

View on HN

The amount of hours our team has wasted on estimating, re-estimating, splitting up stories, simply to make our burn down chart look great is amazing. We would often be forced to split up stories the day before a sprint review, just so that the chart would look like things have progressed, while in reality nothing was completed.

Our sprint planning sessions were a FULL DAY, yes, an entire 8 hours of planning. Because our scrum master wanted a detailed plan of what every engineer would be working on, on every day of the week.

I still remember a certain even where we were forced to adjust our story points, so that we could make a detail a month in the future. Yes, our “agile” team, had a hard deadline that we had to try and make work. This was the business decided that we’ll launch in a month, so now we’ll use our agile methodology to somehow make it magically work. During a full day session to plan for this, I suggested we should drop our scrum board and instead revert to kanban. The scrum master threw me a dirty look and told the business about this, pretty sure that’s why I was moved to another team.

I have suffered through those sprint sessions of hell.

What has worked for me is the following:

- let the most sr tech person ("the architect ") refine the stories maybe with the PM. Then, the same person will point the stories. - The sprint planning is only for presenting the stories to devs and giving some minor adjustments to the points if necessary - The architect may deep dive with a dev for a certain task while pointing it. - That way we have a standard complexity measure. We know different devs will perform different amount of points per sprint . We dont lose time in pointless neverending discussions - it also works well in Mexico where people are not so vocal so the standard poker planning doesn't go well

Sadly because of the way our organisation works, the scrum master pretty much takes ownership of the whole process, he also sells agile to the business side. So if you go against what he says, the business will know that you’re a trouble maker, even if you had the best intentions.

Trust me, our team has tried, sadly the whole business wants to move to agile, and it’s shoved down your throat, wether you like it or not, or even regardless if it’s working for the team.

Eventually I gave up, the amount of energy wasted on these discussions is just not worth it. After a while you learn to say the right things, while also making sure you keep your technical freedom. Sometimes that meant not bringing up certain technical tasks, and overestimating others so that you have time for those other technical tasks.

I raised a similar idea with my team a while back and we stopped doing sprints as an experiment.

We haven't restarted. It has been mentioned a small number of times, but the consensus is always that we don't think it will help. For our team, for what we do, how our work arrives and the nature of the systems we're maintaining and developing, sprints were just artificial lines in the sand.

SCRUM highlights project management problems. If everything works its only overflow is a two hours boring retrospective. Morning meetings is 5 minutes maximum (status ok), estimation - about an hour. Last sprint day is a lazy day - no new tasks allowed, refactor what you can, make presentations etc.

Never heard of successful one week sprints, two weeks looks optimal. Sprint purpose is to show there is no hidden debt ("almost done, oh, no, three weeks more"). Roll out is a bonus.

Failed sprint should be an exception. It as marker, to resolve it you have to resolve real issues:

* team got to much points to implement properly

* no need to fight on story points, ±1 should not matter much

* you can't have two week story, commit something

I have worked very successfully with one day sprints and an end of day catch up - though the was with RAD/DSDM.

Reply on news.ycombinator.com