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

261–270 of 298 posts

Re: Scrum Sucks

#261

Post by pmarreck »

steelframe wrote: post #117
yieldcrv wrote: post #41

Earlier quoted context omitted.

I saw this on my last job! I was already adding time to my work like an extra point or two here and there But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprin…

When I've used Story Points as the team manager, one of the things I made sure of was to completely avoid looking at any given team member's velocity, ever. I only cared about the team velocity, and only for the purpose of estimating risk to the timeline. At the round-table people would report their retired points, and I'd add them to a running tally I kept on a piece of paper next to me. "2+1+0+5+2+2+8+0+1." Then I'…

Smart. Not all contributions can be measured in points. Some team members do a lot of support/mentoring work, for example.

Re: Scrum Sucks

#262

Post by SAI_Peregrinus »

rawgabbit wrote: post #252
SAI_Peregrinus wrote: post #201

Earlier quoted context omitted.

[Waterfall]( https://leadinganswers.typepad.com/leading_answers/files/ori... ) was an incremental design process directly in opposition to the hirearchial process that it's commonly conflated with. That's the paper that coined the term Waterfall, note the contrast between the final Waterfall process from the traditional process (figure 10). "Documentation Driven Development" is basically Royce's Waterfall under a dif…

18F basically follows the process you just described and calls it the agile with a straight face. https://guides.18f.gov/agile/18f-agile-approach/

Most "Agile" proponents think of Waterfall as diagram 1 from the Waterfall paper, when in fact diagram 1 was the process Waterfall aimed to replace. It mostly gets used as a straw man process to oppose, few people seem to have ever read the Waterfall paper to begin with.

Re: Scrum Sucks

#263

Post by ninkendo »

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…

> some people had fewer than 3-4 hours per day to actually work.

3-4 hours per day? That seems like a lot to me! Looking at my calendar, I’m lucky if I get that many hours per week. (It’s not all scrum shit, but let’s just say between sync-ups, status reports, daily standups for multiple projects I’m involved in, architecture reviews, breakouts, etc etc etc, I’m lucky if I get a full work-day’s worth of coding done in a week.)

Re: Scrum Sucks

#264

Post by cpeterso »

steveBK123 wrote: post #215
lowercased wrote: post #46

Earlier quoted context omitted.

"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can r…

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 other over time. (We never bothered with story points, so I can’t compare.)

Re: Scrum Sucks

#265

Post by kevinmchugh »

ajmurmann wrote: post #260
kevinmchugh wrote: post #250

Earlier quoted context omitted.

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'…

> 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. I've only ever been on projects where the backlog was filled by a PM and or lead engineer and then reviewed collectively and maybe some amount of re-shuffling would take place. Are you saying you've been in meetings where the backlog started empty and it was populate with t…

I've never seen an empty backlog, but I've been in meetings the purpose of which is for an entire team to rubberstamp the order of the backlog. This is "grooming" or more recently "backlog refinement". You don't need to do this in kanban.

Re: Scrum Sucks

#266

Post by [deleted] »

The_Colonel wrote: post #251
skydhash wrote: post #238

Earlier quoted context omitted.

They are always deadlines as long as the cycle is official. An informal status update can be done with the project management tool, a 1:1 meeting or a quick team meeting (in this order)

My experience is very different. Sprint wasn't a deadline in any of the companies I've worked at.

[deleted]

Re: Scrum Sucks

#267

Post by [deleted] »

ajmurmann wrote: post #260
kevinmchugh wrote: post #250

Earlier quoted context omitted.

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'…

> 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. I've only ever been on projects where the backlog was filled by a PM and or lead engineer and then reviewed collectively and maybe some amount of re-shuffling would take place. Are you saying you've been in meetings where the backlog started empty and it was populate with t…

[deleted]

Re: Scrum Sucks

#268

Post by wheelinsupial »

ethbr1 wrote: post #77
JohnMakin wrote: post #37

Earlier quoted context omitted.

The last org I was in realized how much time their engineers were spending in agile-caused meetings, much like what you describe, at least half of the working hours in a week - so they made a company-wide rule that no one could spend more than 4 hours a week in meetings. What happened instead were impromptu "ghost" meetings and a ton of stuff done sloppily over chat instead, where I think the hope was that people wou…

To me, RACI charts are a missing component of meetings. Required meeting attendees should consist of the Rs... and only the Rs. As and Cs can be optional, but meetings can conclude without them. Everyone not in the meeting can be updated out of band. "What action is this person taking in this meeting ?" should be a brutally honest question. If the answer is only "listening", then it's a waste of their time. And also,…

Agendas are critical and so is the purpose of the meeting.

Is the purpose of the meeting to inform, decide, workshop, or persuade?

If it's to inform, it should be an email, but some people do not read them, so you need to sometimes read the email to them in a meeting.

If it's to decide, do you have the people that will decide called out in the agenda? Do they have the necessary information or have they done the necessary work to make a decision in the meeting?

If it's a workshop, do you have the invitees pared-down to those that will be actively participating? Is there work they need to complete before the meeting, so they can be active participants?

If it's to persuade, these should be in smaller formats. Preferably 1-1 to start, so objections and resistance are raised in low(er) stakes meetings.

Meetings should end with a summary of decisions, next steps, or some other call to action. Preferably these are recorded somewhere and distributed to the rest of the attendees or a wider audience if needed.

Re: Scrum Sucks

#269

Post by therealdrag0 »

al_borland wrote: post #211
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…

On the opposite extreme, our teams use Jira, kind of structure it like Scrum, but don’t do any of the actual planning. It’s complete chaos and we have a similar level of meetings, maybe more, with everyone trying to figure out what’s going on and when things will be done. The go-to is a 30-60 minute daily meeting with each individual project manager for each project. Sometimes there are 3 project managers working on…

It sounds like you just have poor leadership or poor PMs. Daily meetings should be 15 min with an extended optional “parking lot” to dig into things and everything else should be adhoc meetings with as few engineers as possible, except a weekly and monthly meetings.

I’m a team lead (not manager) and I get over 50% if my time is builder time and I haven’t measured but I’d guess my teammates are around 80%.

Re: Scrum Sucks

#270

Post by ajmurmann »

kevinmchugh wrote: post #265
ajmurmann wrote: post #260

Earlier quoted context omitted.

> 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. I've only ever been on projects where the backlog was filled by a PM and or lead engineer and then reviewed collectively and maybe some amount of re-shuffling would take place. Are you saying you've been in meetings where the backlog started empty and it was populate with t…

I've never seen an empty backlog, but I've been in meetings the purpose of which is for an entire team to rubberstamp the order of the backlog. This is "grooming" or more recently "backlog refinement". You don't need to do this in kanban.

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 backlog with stuff near the top that's no longer relevant or has drastically dropped in importance?

Post reply on HN