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

Scrum is fragile, not Agile

dennisweyland.net

Post reply on HN
Print view View original

61–70 of 329 posts

Re: Scrum is fragile, not Agile

#61

Post by Aeolun »

rileymat2 wrote: post #51
anon1m0us wrote: post #33

Earlier quoted context omitted.

You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. This requires sacrifices like ensuring network connections remain alive, handling exceptions, optimizing queries, abstracting functions for re-use, handling all the data input scenarios, etc. This creates a confusing code-base with lots of IF statements, copy/pasted code, data modifications from several areas of the…

>You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. There is something odd with this, if you did the estimation. Shouldn't the story points/sizing/estimates preclude this? Doesn't the team pick the items for the sprint that they think they can complete?

You can never take a 4 week story in a two week sprint. When would you ever be able to complete it?

Re: Scrum is fragile, not Agile

#62

Post by rileymat2 »

Aeolun wrote: post #61
rileymat2 wrote: post #51

Earlier quoted context omitted.

>You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. There is something odd with this, if you did the estimation. Shouldn't the story points/sizing/estimates preclude this? Doesn't the team pick the items for the sprint that they think they can complete?

You can never take a 4 week story in a two week sprint. When would you ever be able to complete it?

By breaking it down into smaller stories?

Re: Scrum is fragile, not Agile

#63

Post by Aeolun »

analog31 wrote: post #37
anon1m0us wrote: post #14

Earlier quoted context omitted.

The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value." The project mgmt response was, "Attendance at standups is mandatory." Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together. Then I got fired.…

I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.

If you do this often enough. People will assume you are busy if you don’t show up at all.

Re: Scrum is fragile, not Agile

#64

Post by doomslice »

dragonwriter wrote: post #36
clumsysmurf wrote: post #3

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room It is central to the idea of the daily standup is that it is one team . > Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board. If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for shar…

> As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly.

The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predictability goes down. Thus, we are encouraged to not take on extra work if we don’t expect to finish. What this means in reality is that we start working on it without pulling it into the sprint and then get a head start for next sprint.

What’s your take on that?

Re: Scrum is fragile, not Agile

#65

Post by mokus »

addicted wrote: post #44
jboy55 wrote: post #26

Earlier quoted context omitted.

First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I…

However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems…

> Scrum story points are supposed to reflect end user benefits.

That’s not my understanding at all. In our org, that’s the role of backlog priorities. Story points are the cost to get there, and are explicitly a tool to estimate relative amounts of effort involved.

If tech debt is to be incurred, it is expected that engineers negotiate that, and that other estimates will change as a result (and/or other tasks be created to track that debt). But then, nearly 100% of the managers in our org are, themselves, engineers or SMEs in the field they are managing, so they have realistic goals and understanding of the sausage-making process. What you’re describing really does sound more to me like a management problem than a process problem.

Re: Scrum is fragile, not Agile

#67

Post by taneq »

icedchai wrote: post #49
barrkel wrote: post #31

Earlier quoted context omitted.

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…

The biggest problem with Scrum is it lacks any sort of design phase. You do the minimum. Oh, it doesn't work quite right? We'll fix it in the next sprint... The "spiral" model is closer to a true iterated waterfall. I've seen it used successfully in more mature companies.

It's like "build one to throw away", in that the goal is to rapidly explore the feature space and discover useful features, but what actually happens is that it's a trap and you won't throw away something that works no matter how poorly implemented.

Re: Scrum is fragile, not Agile

#68

Post by forinti »

xyzzy_plugh wrote: post #54
anon1m0us wrote: post #32

Earlier quoted context omitted.

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many…

This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!

Best PM I ever had dropped by every week or so to ask if we needed anything.

Re: Scrum is fragile, not Agile

#69

Post by jrochkind1 »

addicted wrote: post #44
jboy55 wrote: post #26

Earlier quoted context omitted.

First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I…

However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems…

Eh, the idea that a team should be no larger than the number of people that can meet together is not unreasonable, if also not incontrovertible. What makes a team a team if they can't meet together as a team effectively?

Re: Scrum is fragile, not Agile

#70

Post by johnksawers »

addicted wrote: post #44
jboy55 wrote: post #26

Earlier quoted context omitted.

First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I…

However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems…

I think the scrum team size is determined in part because communication overhead is exponential, getting beyond 6-8 people means the whole team has to spend a lot of extra time coordinating. This is true regardless of whether you're dong scrum or not. It's true some teams may be correctly sized at 20, but I would suspect that breaking that into 2-3 other teams would be a benefit most times.

Story Points represent effort and uncertainty, not business/customer value - those are Business Value Points. Devs are only committing to X story points per sprint. If refactoring is needed, it's built into the story points, or added as it's own task. And as others have said if the Product Owners don't take engineering input on paying down tech debt/infrastructure/internal tooling, then you have a broken company no matter what process you're following.

Post reply on HN