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

251–260 of 298 posts

Re: Scrum Sucks

#251

Post by The_Colonel »

skydhash wrote: post #238
shortlived wrote: post #213

Earlier quoted context omitted.

Yeah, you are doing it wrong if scrum is deadlines. I've worked with people who had to pull all nighters to get all sprint content done before the sprint closes. I'm using it more as a window to do some cheap analysis on our progress.

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.

Re: Scrum Sucks

#252

Post by rawgabbit »

SAI_Peregrinus wrote: post #201
Scubabear68 wrote: post #10

One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.

[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/

Re: Scrum Sucks

#253

Post by The_Colonel »

unethical_ban wrote: post #108
_ea1k wrote: post #54

"Way of work should be defined at a team level by its people, not by the company." - This is basically the origin of scrum. Essentially every problem ascribed to scrum is its departure from this origin story. Scrum is about making each team work better, but somehow it turned into the same weird top-down imposed structure that it was supposed to replace. 2 week sprints are mandatory for all teams? They all have to sta…

Ha! At my old employer they used "Scaled Agile Framework" (SAFe). About a dozen teams of developers and operations people got together once a QUARTER to determine what big epics/objectives to complete, and then develop stories and estimates (points) for those stories and roughly which sprint they would fall into within the "iteration", as the quarter was called. Every team on the same sprint schedule. Fibbonaci story…

The quarter is called "increment". "Iteration" corresponds to sprint from Scrum.

> About a dozen teams of developers and operations people got together

The S is for "Scaled" for a reason. Yes, large & complex projects need planning on several levels and the timeframes are longer. Nothing surprising.

Re: Scrum Sucks

#254

Post by nine_k »

a_square_peg wrote: post #236
nine_k wrote: post #219

Earlier quoted context omitted.

Kanban came from elsewhere. The word comes from post-war Japanese car factories, but the principle is older. Kanban boards were physical boards, with tokens representing various machines' or workers' availability, and the presence of things to work on. It's more a work-scheduling mechanism for known, understandable, repeatable work. https://en.wikipedia.org/wiki/Kanban

Interesting to know - thanks for the info. Strange to think that something designed for 'known, understandable, repeatable work' got adopted by software development.

Some software-related work, like regular changes to a website, or regular SRE work, is understandable and relatively repeatable.

Software development work usually isn't. Software development, by its nature, automates away everything repeatable and predictable, so unpredictable and never-before-seen stuff dominates.

Re: Scrum Sucks

#255

Post by The_Colonel »

lapcat wrote: post #241
The_Colonel wrote: post #239

Earlier quoted context omitted.

> 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.

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

The instances of people not attending standups I've seen were just symptoms of a larger problem, and such people did not last long in the company.

Re: Scrum Sucks

#256

Post by lapcat »

The_Colonel wrote: post #255
lapcat wrote: post #241

Earlier quoted context omitted.

> 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.

> What about "forgetting" to attend a 10 minute meeting? The instances of people not attending standups I've seen were just symptoms of a larger problem, and such people did not last long in the company.

You didn't answer my question. Can they be fired or not? And if yes, what makes it different from emails?

Re: Scrum Sucks

#257

Post by theptip »

After working in teams using Scrum and fully unstructured “trust the engineer”, I agree there are certain parts of Scrum that feel like dead weight / overkill.

Daily standup can feel productive when you are doing it, but I think you have to be a very small and nimble team with high density of juniors for it to be appropriate to meet that frequency. With a mostly-senior team folks just reach out when needed to unblock each other, and proactively broadcast async updates. Tooling to encourage this “ambient information” is I think under-invested. Takes a lot of discipline in Slack to prevent channels from devolving into noisy discussions.

I think a lot of teams think they need more predictability than they actually do, and sizing/points are overrated. Again this is contextual; in some projects you really do need to forecast a Q/H roadmap for customers. But if you are shipping every week or two, sizing barely matters as you can just Kanban it and keep picking the most important item to work on each sprint.

I think retro is mostly time wasted. You can fill an hour per two weeks with it but I’m not convinced it’s the best use of that time when you are moving fast. Async tools that can measure a pulse survey & flag common themes that are bright red/green is probably a better place to be.

I think some sort of stakeholder review on a regular cadence is great, and sadly is the bit that is taken least seriously in Scrum IME. When stakeholders (in small companies this means CEO and the rest of leadership!) take this seriously you get a great feedback loop. Too often I see folks skipping as they have “real work” to do. I think this also points to lessons for the engineers; really need to keep things snappy and customer-focused. Have your tech-facing demos another time. Or, even better, record your product facing demos and post them, so you can get feedback async. If the CEO comments regularly on these it can still provide that feedback that the meeting / demo is valued and important.

Re: Scrum Sucks

#258

Post by _ea1k »

belval wrote: post #180
_ea1k wrote: post #154

Earlier quoted context omitted.

Don't forget to tag and label every story appropriately, use the corporate standard for sprint names, and file those tps reports on time. That would be great.

I feel like that's unfair. It's normal in a company to answer to someone and its normal for that someone to want some way to answer the question "are we on track for X" when asked by their superior (whoever that may be). The larger the company the more that statement becomes true because the number of interconnect for N employees is O(N^2). That does not excuse making the whole thing stupid and painful, but accountab…

Of course! The problem is that this "accountability" is the grease on the slippery slope towards doom.

If I need every epic, story, task and subtask to be labelled in the correct way for your organization, then I no longer have an autonomous team that is able to self organize to maximize its own efficiency.

If I don't have that, I no longer have agile. There are better ways than turning agile into a caricature of its former self.

Re: Scrum Sucks

#259

Post by _ea1k »

The_Colonel wrote: post #253
unethical_ban wrote: post #108

Earlier quoted context omitted.

Ha! At my old employer they used "Scaled Agile Framework" (SAFe). About a dozen teams of developers and operations people got together once a QUARTER to determine what big epics/objectives to complete, and then develop stories and estimates (points) for those stories and roughly which sprint they would fall into within the "iteration", as the quarter was called. Every team on the same sprint schedule. Fibbonaci story…

The quarter is called "increment". "Iteration" corresponds to sprint from Scrum. > About a dozen teams of developers and operations people got together The S is for "Scaled" for a reason. Yes, large & complex projects need planning on several levels and the timeframes are longer. Nothing surprising.

We all know that. There are even some good things in SaFe.

Where it loses value is that it imposes those organization level planning ideas at too many levels and ultimately impedes the most effective teams.

Re: Scrum Sucks

#260

Post by ajmurmann »

kevinmchugh wrote: post #250
ajmurmann wrote: post #191

Earlier quoted context omitted.

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

> 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 the entire team in the room?

Post reply on HN