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

441–450 of 459 posts

Re: I don’t believe in sprints

#441

Post by marcus_holmes »

lwhi wrote: post #360
marcus_holmes wrote: post #87

Earlier quoted context omitted.

Agile doesn't have sprints. Scrum has sprints. And Scrum is all about solving management problems not developer problems. You can just drop sprints without replacing them with anything.

I'm sorry, but; no. Developers aren't the only part of a product team. You can't just drop sprints without failing to meet other objectives.

Sprints aren't the only method of agreeing objectives. You can just say "we plan on getting this done by next Wednesday".

I've dropped sprints on 2 teams now, and improved our cadence both times.

Re: I don’t believe in sprints

#442

Post by jrs235 »

WorldMaker wrote: post #411
jrs235 wrote: post #333

Earlier quoted context omitted.

>stakeholders weren't onboard with no fixed cadence of deliveries. Can the fixed cadence of deliveries be weekly or semi weekly status update of cards on the board? (Note: the view of the board should always be available to stakeholders, they may need to hold their breath for a week until a more in-depth status meeting of current cards on the board...)

Yep. Also I've never seen a Kanban operation deliver everything to Production as soon as it hits a "Done" column and there's no reason not to "time gate" (once every fortnite, just like Sprints are supposed to be, for instance) a Production column "pull". I think that's easily missed in Kanban versus Scrum discussions: every Kanban column is supposed to be "pull" rather than "push". Production "pulls" finished UAT st…

Ah yes! I forgot about the "pull" mechanism of kanban. This also helps identity bottlenecks and discover where more "resources" (::barf::) are needed or where re-allocation of "resources" should occur.

I need to reread the following books:

Kanban: Successful Evolutionary Change for Your Technology Business

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

The Goal: A Process of Ongoing Improvement.

The Deadline: A Novel About Project Management

Re: I don’t believe in sprints

#443

Post by bluGill »

jacobyoder wrote: post #268
pnut wrote: post #178

Earlier quoted context omitted.

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.

> sprints give more discretion to the teams when they do. i was part of an 'agile' team in 2019 (6 mo contract). I wasn't there long enough to have strong views on work items or priorities, but did watch the interactions between others. It was a decently organized team inside a (fast) growing org - lots of challenges there. But overall, there was a decent balance. Worked on another smaller team longer - 2 years. As t…

On a 6 month contract you haven't been around the code long enough to know what is tech debt and what is a good solution for a complex solution.

Though your point is correct - you rarely are given time to fix tech debt. If you switch to a long term employee, then you should intentionally slow your velocity a little to fix tech debt. By the time management catches on you will have fixed enough that an improvement is visible and so you have proven yourself, and thus will be allowed to do more of it.

Also note that a story isn't done until refactoring is done. Sure it works, but if the code is a mess your story isn't done and you don't move onto the next one. Many developers fail to force this, but as a professional this should be part of your code of conduct and thus not optional no matter what the deadline.

In any case the point is you will never be officially given those 5 points - but you can take them by force.

Re: I don’t believe in sprints

#444

Post by bluGill »

benrow wrote: post #301
pnut wrote: post #178

Earlier quoted context omitted.

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.

Agreed. As an aside, one thing just came to mind. Even if you're bringing tech debt tickets into each sprint, there's a possibility they'll get picked up last - fine, unless they keep getting pushed back! Part of me thinks this could be mitigated by reducing the velocity expectation. But there tends to be an overarching sprint goal relating to product work, and this often invites extra scope due to unforeseen impedim…

There are two ways management can handle getting things done on time: commit to taking only 80% of the teams capacity, thus ensuring there is plenty of buffer; or commit to the full thing, and accept that some things won't get done. If (as most do despite Agile warnings about it being wrong) your management wants you to get done 100% of what you commit to, then as a team you need to hide 20% of your capacity from management.

Re: I don’t believe in sprints

#445

Post by Kalanos »

hirvi74 wrote: post #395
Kalanos wrote: post #227

Earlier quoted context omitted.

Love it. Lots of agile benefits for devs. Less hand-wavy requirements. You get to say how long your work is going to take

We have vastly different agile experiences, my friend.

i've seen a lot of ppl do it wrong and claim it doesn't work. it's like not obeying the rules of the road and getting mad when things get chaotic

Re: I don’t believe in sprints

#446

Post by AstralStorm »

the_af wrote: post #413
peteradio wrote: post #352

Earlier quoted context omitted.

The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?

> The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints? I don't know, your problem statement doesn't allow me to formulate an answer. I suspect whatever the project, it can be split into a series of more manageable chunks.

It does not work if none of the chunks produces value for the customer, yet is necessary from engineering or bureaucratic point of view.

And sometimes you do hit a brick wall or bite something you cannot chew yet must digest.

Re: I don’t believe in sprints

#447

Post by AstralStorm »

marmarama wrote: post #138
izacus wrote: post #71

Earlier quoted context omitted.

One of these days we might even hear of an example where following "agile" actually panned out. The question is - before year of the Linux desktop or after?

Essentially every project I've worked on in the last 9 years has been agile, most of them Scrum, and almost all of them succeeded in achieving their goals. There's a clear correlation on all of them between the skill of the project manager at applying the agile approach, and how difficult the delivery was. Prior to that, I worked (as did most people) on waterfall-style projects, and the success rate was only about 50…

Usually when agile approaches (kanban or scrum) fail it is because there's an unsolvable bottleneck. Typically too small team, lacking knowledge or skill for the scope, problematic environment (development or socially) or someone is pushing "done" work causing skyrocketing development debt that quickly comes to a head - typically a prototype remains in production, switching too early to maintenance mode for business reasons.

Waterfall cannot identify those risks without huge experience. Scrum tends to exacerbate some of them. Kanban with sufficient number of phases tends to expose the problem, but not necessarily fix it.

Re: I don’t believe in sprints

#448

Post by phailhaus »

maxsilver wrote: post #266
phailhaus wrote: post #121

Earlier quoted context omitted.

Apple comes out tomorrow and announces the new iPhone 15. "We do not know when it will be ready. It might be tomorrow, or just as likely it will be in a hundred years." Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!

Apple doesn't come out and announce a new iPhone 15 until it's already 90%+ done and working, and therefore can accurately predict some kind of reasonable release window. And software that can't be estimated is still useful, even if you can't plan releases around it yet. "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pr…

> "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pretty silly statement, right?

That's exactly how it works though. Imagine Apple's stock price if they announce the Apple Car, without a release window. Now imagine that they come back the next day and say "oh by the way, we're aiming to release it in 2086." What happens to the price? It goes down. There was an implicit estimate used to judge the value of Apple.

Likewise, all software has an implicit estimate. There has to be! Without one, it's worthless.

Re: I don’t believe in sprints

#449

Post by LtWorf »

yucky wrote: post #434
LtWorf wrote: post #176

Earlier quoted context omitted.

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.

A meeting to plan for the meeting. Instead of turtles, it's meetings all the way down.

I never said a meeting. That says a lot about you :p

Re: I don’t believe in sprints

#450

Post by the_af »

AstralStorm wrote: post #446
the_af wrote: post #413

Earlier quoted context omitted.

> The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints? I don't know, your problem statement doesn't allow me to formulate an answer. I suspect whatever the project, it can be split into a series of more manageable chunks.

It does not work if none of the chunks produces value for the customer, yet is necessary from engineering or bureaucratic point of view. And sometimes you do hit a brick wall or bite something you cannot chew yet must digest.

Oh, to clarify: I don't believe in Scrum's "you must be able to release to the customer at the end of each iteration". That's a piece of fiction that I think almost nobody believes in anymore.

It still makes sense to have intermediate deliverables for internal milestones though.

Post reply on HN