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

241–250 of 298 posts

Re: Scrum Sucks

#241

Post by lapcat »

The_Colonel wrote: post #239
lapcat wrote: post #230

Earlier quoted context omitted.

We know scientifically that exercise is important. I highly doubt the same level of evidence exists for the importance of these short meetings. Also, if your boss tells you to read the emails, and you don't, then you can get fired. You can't get fired from your job for not exercising. If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.

> Also, if your boss tells you to read the emails, and you don't, then you can get fired. The boss has no easy way to tell if you read the emails or not. The consequences of lack of information are often hidden / long term. In many countries, it's pretty much impossible to fire employees for forgetting to read an email. > If you can ignore the emails and not get fired, that's proof in itself that the emails are not i…

> In many countries, it's pretty much impossible to fire employees for forgetting to read an email.

What about "forgetting" to attend a 10 minute meeting?

> I'll try a proof in a similar style

It wasn't a similar style.

Re: Scrum Sucks

#242

Post by The_Colonel »

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.

> have always refined features as part of the natural flow.

"natural" as in "law of nature"? Or is it just a process which crystallized in the course of your career as something which makes sense to do?

Scrum, and other methodologies are mostly a collection of such processes which proved to be useful, are somewhat standardized for learning and communication.

One can reinvent many of the Scrum processes independently, but I kinda don't see the point. Just like I'd rather use a finished library / framework rather than try to hack together my own.

Re: Scrum Sucks

#243

Post by The_Colonel »

torginus wrote: post #107
Aurornis wrote: post #7

I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…

Never in my life have I encountered anyone from the engineering side who spoke positively about scrum. It's always the consultants and scrum masters and their ilk who push the agenda. Never have I ever heard about any story about agile making things better.

I'm old enough to have extensive experience from before agile methodologies were in vogue and things are generally better with Scrum / Agile than they were before, ceteris paribus.

Sometimes the process worked better, sometimes worse. It depends a lot on the company culture and people. The company I'm currently at has a very good process (SAFe).

(I'm an engineer to clarify)

Re: Scrum Sucks

#244

Post by ssrc »

klysm wrote: post #61
BearOso wrote: post #58

The term scrum comes from rugby, and it has nothing to do with organization. It's literally when something goes wrong, pack everyone together and get the ball moving again. Symbolically, obviously, ball=project. The problem, like everything these days, is corporatism. Things have been added to the old development model to create positions for knowledgeless managers to do nothing and make money. Agile means fast witho…

Appeal-to-etymology is an especially weak form of argument - the origin from rugby doesn't matter.

You are right, but in this case I have some sympathy for the argument. If all the technical terms in one methodology (scrum, sprint, velocity, commitment, ...) look like they were chosen not in good faith, well...

Re: Scrum Sucks

#245

Post by skydhash »

nine_k wrote: post #222
the_other wrote: post #159

Earlier quoted context omitted.

Sounds good. 15 people seems too big, but if you're keeping it under 10 minutes then all power to you. Very few people care about "what did you do yesterday?". It's already over, by that point. There's a lot of benefit to removing that one. In my team we do it like this: - how are the nightly tests? (we've actually dropped this in recent months) - what's in the Test column, and does it still need manual testing? (we…

> Very few people care about "what did you do yesterday?" ...except the people for whom what you have accomplished is a dependency in their work. It can be a direct code change you'd have to merge into your current branch, or something you might want to start using (or finally stop using). It may be even something you have to contemplate on, and it may affect your work much later. Work of people in a team is inevitab…

If you have deps, it’s better to have a direct meeting with both teams in order to resolve mishaps and have a channel of communication setup for that. Daily standup is a poor replacement for that.

Re: Scrum Sucks

#246

Post by edgyquant »

lars_francke wrote: post #163
AtNightWeCode wrote: post #56

Earlier quoted context omitted.

Just by switching from Scrum to Kanban one can improve progress a lot. For being two very similar pull based systems the difference in effectiveness is just incredible.

Agreed. We use Kanban and are very happy. We used to not do any estimates but have voices from others asking for them to do better planning of marketing and sales activities. I understand where they are coming from but so far it's mostly guessing So: Do you do estimation in Kanban and if so, how?

I think generally you should be able to break some feature up into a series of very small tasks that can be estimated. So you may not be able to estimate an end to end feature accurately but you should be able to give rough ETAs for when different functionality will start to trickle in

Re: Scrum Sucks

#247

Post by hikarikuen »

lars_francke wrote: post #163
AtNightWeCode wrote: post #56

Earlier quoted context omitted.

Just by switching from Scrum to Kanban one can improve progress a lot. For being two very similar pull based systems the difference in effectiveness is just incredible.

Agreed. We use Kanban and are very happy. We used to not do any estimates but have voices from others asking for them to do better planning of marketing and sales activities. I understand where they are coming from but so far it's mostly guessing So: Do you do estimation in Kanban and if so, how?

[dead]

Re: Scrum Sucks

#248

Post by rawgabbit »

gtmitchell wrote: post #210

I'm a scientist that through a lateral career move has ended up doing something akin to software development. This means for the last few years I have attended daily scrum meetings for the project I'm working on. Perhaps it's my inexperience with software development, or maybe it's specific to the company I work for, or the people on my team, but but I find the entire process a gigantic waste of time and mental energ…

https://guides.18f.gov/agile/18f-agile-approach/

Re: Scrum Sucks

#249

Post by The_Colonel »

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.

Manifesto came out in 2001, you need to take into account the context of that time - the processes were often much more heavy-handed (esp. in big companies) than they are now. This manifesto item was never about not creating any processes.

Re: Scrum Sucks

#250

Post by kevinmchugh »

ajmurmann wrote: post #191
kevinmchugh wrote: post #150

Earlier quoted context omitted.

The obvious alternative to scrum for many teams who wish to be agile is something based on kanban.

Which is another flavor of Agile which is what everyone is always complaining about. I'd take some form of Kanban any day over doing rigid Scrum by the book. Kanban needs a lot very similar meetings though. You still need to fill the backlog, discuss the tickets. If you were to do Kanban by the book as described by the Agile Alliance, you'd still do standups, retro under a different name etc.

In my experience people complain about strict processes that books or consultants say must be followed. I've rarely heard someone complain about the content of the agile manifesto. So start with what you've got, and iteratively keep what works and chuck what doesn't, until you have a process that works.

I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.

Post reply on HN