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

Scrum Sucks

blog.mb-consulting.dev

Post reply on HN
Print view View original

291–298 of 298 posts

Re: Scrum Sucks

#291

Post by leejo »

pluies wrote: post #290
leejo wrote: post #205

Earlier quoted context omitted.

To expand the analogy further the scrum, in modern rugby, is the worst part of the game and has gone through several iterations the last couple of decades to reform it as it often ends in a stalemate or arbitrary penalty to one side (as good as a coin flip), or worse: a head injury. The approach has seen the game settle with "Crouch, Bind, Set", which seems to be a good compromise. And yet the hooker always, always A…

You're in a lot of trouble if your _hooker_ is feeding the scrum!

Gah! Brain, I was thinking about which player usually strikes the ball first (hooker) rather than who feeds the scrum (scrum-half). Point still stands though I don't think I've seen a straight feed in years, at least in the Six Nations matches.

Re: Scrum Sucks

#292

Post by steveBK123 »

cpeterso wrote: post #264
steveBK123 wrote: post #215

Earlier quoted context omitted.

Also don't forget story point Goldilocks. We don't create 1 point stories, you need to roll this up with another story! Hey we don't do 13 point stories, you need to break that one up! 8 points? you sure that isn't a 5? 2 points, 3 points.. what's the difference just mark it as a 2. OK so basically we just have 2s & 5s then? Amazing.

If you try to right size tasks, you can just count tasks instead of estimating them. This approach even has a catchy brand name in agile circles: #noestimates. In every team I’ve tracked, the task count burndown velocity was impressively linear, whether looking at weeks, months, or years of data. I think we can thank the Law of Large Numbers, with shorter than average and longer than average tasks balancing each othe…

The problem with Agile induced "right sizing" of tasks is that you artificially split atomic units of work into multiple tickets.

A single deliverable is now 3-5 different tickets that might get split across sprints. It now becomes harder to express when a piece of atomic functionality will be delivered because you need to track with dependencies across the tickets, etc.

So it feels like contortions to make reality fit into Agile which negatively effect reality.

Let's say we are using Agile in the kitchen and we have 3 tickets - 1) research recipe, 2) collect ingredients, 3) bake cake. These are logical and understandable to a stakeholder. You can assign them different story points / sizes / durations / whatever. It's relatively easy to express the dependency and also keep it in your mental model. Each has a deliverable - 1) recipe & ingredient list 2) the ingredients 3) the cake.

However Big Agile Coach argues that really it should be 1a) research recipe, 1b) collate ingredients required, 2a) research pricing on ingredients 2b) create per-vendor ingredient lists 2c1) buy ingredients at vendor 1, 2c2) buy ingredients at vendor 2, 3a) clean kitchen 3b) prepare cake batter 3c) bake cake 3d) cake frosting/finishing

OK which of these 9 tickets depend on which / which can be parallelized / which are best to keep with a single dev, which should be done within a single sprint vs split across? Etc.

Re: Scrum Sucks

#293

Post by rsbrown »

I have my own (and many) criticisms of Scrum, but this article is so poorly written that I cannot say whether the author's views align with my own. I couldn't make it beyond the first few paragraphs.

Re: Scrum Sucks

#294

Post by ryathal »

a_square_peg wrote: post #183
nine_k wrote: post #140

Earlier quoted context omitted.

Re-reading http://agilemanifesto.org/ (which is ridiculously short) and comparing it to an "agile practice" around you is very eye-opening. Some companies actually practice agile development, and it works. They are small, nimble, and have very little process. But then they grow...

Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.

Scrum came from a world where product folks and developers never directly talked to each other. Everything was a formal written request with some requirements and there were SLAs for how long developers could look at it before providing questions and estimates back. After one (two if you're lucky) round(s) of questions a deadline is established, and work begins.

In that world, creating a single product owner that had the full complete say of this is what will happen that met with developers on a daily basis is a huge improvement of individuals and interactions. This is the single biggest win of Scrum, getting people to just talk to each other regularly, by having mandatory meetings all the time. If an organization has good communication or a product is too large for a single person to manage, Scrum ceases to be as useful option.

Re: Scrum Sucks

#295

Post by ajmurmann »

kevinmchugh wrote: post #277
ajmurmann wrote: post #270

Earlier quoted context omitted.

Don't you need to go over newly added tickets and ensure the tickets are clear, order makes sense, etc? Whenever we've skipped this some issues would emerge when tickets get picked up later. Depending on the project domain and if a PM or engineering lead wrote the tickets the issues would be either more about technical issues or misunderstanding of business requirements. > I've never seen an empty backlog How about a…

Tickets are often written imperfectly but that doesn't necessitate a standing meeting for the whole team imo. Make your pm and em hash them out, make the most informed engineer write the ticket, but don't make everybody watch. If the top of your backlog is uselessly stale, you're spending too much time writing tickets in the distant past and not enough recently (or maybe congrats on your velocity?). A ticket that's s…

What you are describing is entirely reasonable, but again still a lightweight Agile process. The thing that I don't understand is what the people want who keep complaining about all Agile, not just (rigid) Scrum in particular. I've worked with XP, Scrum, Kanban and versions of those adjusted to particular teams and companies. If someone doesn't want any Agile and doesn't want Waterfall, wtf do they want?

Re: Scrum Sucks

#296

Post by pillefitz »

RaftPeople wrote: post #224
pillefitz wrote: post #202

Earlier quoted context omitted.

How do you refine features? How do you discuss team improvement measures? How does prioritization happen if you're working on a product? The answer might be simple for small teams, but a lot more complex for larger teams, where the result might look eerily close to Scrum. One difference would be that meetings will take place infrequently and only "as needed", where I wouldn't trust most teams to recognize their needs…

> How do you refine features? I'm really curious about this question, are you thinking that not having Scrum makes it's harder to refine features? I'm trying to understand what assumptions you are making, because I've never worked in a Scrum environment, but have always refined features as part of the natural flow.

No, but I believe that whatever you're doing resembles what is done in scrum. Gather information, discuss with your colleagues, create a plan. Scrum enforces that colleagues talk to each other, which I learned is not always the case.

Re: Scrum Sucks

#297

Post by PaulHoule »

cableshaft wrote: post #217
CharlieDigital wrote: post #52

Earlier quoted context omitted.

> everyone meeting This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup) I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't…

> Big red flag is there is a daily all hands standup Something I've seen for the first time at my current project is instead of a daily standup, there's a daily thread to report what you've been doing in Slack instead. And then as long as there's nothing people want to go over, the actual standup meeting is skipped. We sometimes go a 2-3 weeks without an actual stand up call. It's pretty nice. Even if not, the calls…

We do that where I work and we did it at the last place.

I found it stressful to write the summary of what I did yesterday in the morning because I’d been thinking about other things in the interim. I discovered the “life hack” of filling out my report in the afternoon at quitting time which makes me, from the viewpoint of everyone else, the first to report. I find it really easy to do and when I get in the morning I have a plan in front of me which helps me carry forward my momentum from the previous day.

Re: Scrum Sucks

#298

Post by kjs3 »

onion2k wrote: post #283
kjs3 wrote: post #161

Earlier quoted context omitted.

I don't think it's that 'bizarre'. My team has been an overlay team for years. We provide services to many teams. Since the glorious transition to agile and product focus, we had to sacrifice someone to be the product owner, so their 'whole job' is overhead management, which they hate. Now, every team wants someone from my team in every standup ("but we'll be blocked if a question for your team comes up and no one is…

every team wants someone from my team in every standup In agile you're supposed to know what's going into your sprint, and each ticket should meet your "definition of ready". Teams shouldn't need someone on hand because they should already have refined and unblocked issues before the ticket was added to the sprint. Whatever it is you're doing it isn't agile.

Well sure. That's the default response: "It's not us, it's you". But I can't help thinking "We have dozens of dedicated 'agile leaders', several dozens more 'agile coaches' who have various certifications, commitment from management and have hundreds if not thousands of people who have gone through multi-hour (at least) agile training. If we're still doing it so obviously wrong, maybe it's the methodology and not the people.".
Post reply on HN