Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don’t believe in sprints

robinrendle.com

Post reply on HN
Print view View original

171–180 of 459 posts

Re: I don’t believe in sprints

#171

Post by scotty79 »

melling wrote: post #116
hurril wrote: post #6

This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…

Yes, people like predictable. Tell management every project will take a month, and meet that expectation, then management will be happy. While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective. So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estima…

> you are forcing people to make [very] conservative estimates

My experience is that once developers make conservative estimates they are ignored because business side of things would rather prefer to imagine they'll get the system completed this decade, not when estimates show. So instead of working according to estimates everybody is crunching and cutting corners and project gets delivered in some useful form in less than a year.

Re: I don’t believe in sprints

#172

Post by elboru »

stingraycharles wrote: post #24
gbro3n wrote: post #11

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…

Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines). Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses…

> Sprints are really just a form of pressure

I’ve felt the opposite. My team switched from “Scrum” to “Kamban”. Then after a few months the sensation of having an endless pile of cards, without a time frame, felt overwhelming.

In the other hand, having a short lived cycle used to help me manage my time. If for any reason one day I was not able to accomplish much, I knew I still had a few more days to compensate. The same was true for the opposite, I could be really productive a few days and then I could relax for the rest of the sprint.

That workflow really worked for me. With Kanaban I feel the pressure to always be “productive”, because I don’t have a clear reference on how “relaxed” I’m (or not), during the week or month.

Maybe I just need to find a different reference. I guess my point is that sprints don’t necessarily mean pressure for everyone.

Re: I don’t believe in sprints

#173

Post by wwilim »

schwartzworld wrote: post #162

I loved working in sprints. My last two jobs have used the term, but not the ceremonies, and it's not unusual for tickets to be quietly moved from sprint to sprint while in progress. Without agile ceremonies, the quality of tickets can really vary depending on who is writing them. I think there's something to be said for a group of devs looking at a task and deciding if there is a clear AC and discussing how difficul…

I agree wholeheartedly, increasing quality of cooperation with stakeholders is exactly why I think it's great in certain scenarios

Re: I don’t believe in sprints

#174

Post by invalidusernam3 »

I generally avoid rants on HN, but I can't resist this one because this post is particularly irking.

I absolutely hate useless opinion posts like this. They're incredibly vain. There is zero substance to the authors argument beyond "sprints are inconvenient".

I can only assume the person who wrote this lacks much real world development experience, because anyone who has worked at multiple companies will tell you there is no one size fits all way of doing development. Post like this are pure Dunning-Kruger effect.

Re: I don’t believe in sprints

#175

Post by user3939382 »

I've been bemused watching the rise of agile over the last (10?) years since my background is in building software for large/multinational non-tech companies. They have VPs and accounting departments with budgets and they want to know exactly how much they're spending before they spend the first dollar. Whether or not they should, they don't see the uncertainties in estimating software development as their problem.

My solution to this is waterfall, and charging for a rigorous requirements analysis process up front, which I, in turn, estimate the cost of by having the client submit their requirements (as they know them so far) in detail in writing up front.

I've been surprised in (the practical version of) agile how often time is wasted revising the same feature 5x that could have been done once if a modicum of time and thought was put into business and technical requirements.

I am however a believer that people do things for a reason, it does probably have advantages for R&D or inside technical product companies.

Re: I don’t believe in sprints

#176

Post by LtWorf »

pevey wrote: post #63
LtWorf wrote: post #18

Earlier quoted context omitted.

In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.

I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.

That means the task is underspecified. You should schedule a "figure this out" instead, and once the task is well defined it can be done.

Re: I don’t believe in sprints

#177

Post by ethanwillis »

astura wrote: post #136
rob74 wrote: post #112

Earlier quoted context omitted.

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what…

If you have subpar project managers, product owners, and lead developers on your team would you really be better off without structured sprints? I guess, I'm asking, is there something specific about agile that makes a subpar team worse?

It can make them believe they're good.

Re: I don’t believe in sprints

#178

Post by pnut »

bluGill wrote: post #149
stingraycharles wrote: post #24

Earlier quoted context omitted.

Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines). Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses…

Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release. It doesn't matter if you have sprints of kanban, if there is a…

Funny how whenever I've done kanban, top tech debt items always are eternally pushed down to #5 or 6 in the backlog, never to see the light of day.

I have my criticisms for sure, but sprints give more discretion to the teams to carve out space for multiple types of priorities held in balance, and lock that ratio in for a period of time.

Re: I don’t believe in sprints

#179

Post by ozim »

polotics wrote: post #39
gbro3n wrote: post #11

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…

KANBAN is good at ensuring you do not have too many themes on your plate at the same time. Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored. Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny. If any…

From my experience sprints ensure that stuff is "good enough" and pushed out the door. Like QA having idea that some icon is not aligned - but yeah it is end of the sprint close it and fix in next iteration and get to work on other thing that has priority now - not aligning some unimportant details.

So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea.

Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".

Post reply on HN