Live data from Hacker News

Eight points for one team is two points for another team

lloydatkinson.net

51–60 of 105 posts

Re: Eight points for one team is two points for another team

#51
post #2

Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…

Here's one to add onto your list: pair/mob programming is bosses weaponizing employees against each other to "prevent goofing off".

I've started to form a belief[0] that large software projects in general are A Bad Idea. Whatever it is, if it requires more than a handful of people to build, it's probably for the greater good of everyone--the workers involved, the users, humanity in general, anyone-not-identifying-as-shareholders--that it not be done.

Software is the only thing I can think of where the input effort of creating it is completely divorced from the output work it can churn through. The right program at the right time, written in 10 minutes by just the right person, can save hundreds of years of otherwise manual labor.

There's a sort of sense that arithmetic got us out of the stone age, calculus fed the world, computer programming gave us the stars. That sort of power is far too important to imbue into corporations.

When you get a large group of people together, they start to think of themselves as Important. And when people think of themselves as Important, they start to think the work they do is Hard. And when they think the work they do is Hard, they start to think the software to help them do their work should be Complex. And none of it comes out of anything other than "we have a large group of people together."

Like, microkernel operating systems have a reputation for being slow based on early experiments with them from the 1980s. There are modern microkernel systems that are perfectly fast and efficient and yet people still think "monolith go brrrrrr" and not "all my software lives here" is the reason Linux is any good.

Like, I've seen people pitching blockchain-based solutions for municipal information and issue-reporting services, like anything beyond the most basic, not-completely-incompetent, traditional RDBMS is really necessary for such a project.

Like, there's a serious cohort of economists that think that the best way to handle social safety benefits is to just give them to everyone who asks, no questions asked, because otherwise the management of welfare benefits gets to be so expensive that it eclipses any potential savings against "fraud". And I'm inclined to believe them.

I see people talk about "there's no such thing as a 10x programmer". I think these people have been stuck in ossified institutions so long that they have no idea what it looks like to see a person fly. Cut away 90% of the currently employed software developers. Dissolve the Googles and Facebooks of the world. Don't replace them with anything. Leave us with the 10% of crafstpeople who can actually work through a problem on their own. And make them report directly to the C-suite. No more middle managers. No more grunt work of CRUD forms. If it can be done on paper than it's a waste of time to write software to do it.

[0] AKA this is a feeling, not something I've created a double-blind randomized trial to study, dear pedantic HN reader.

Re: Eight points for one team is two points for another team

#52
post #12

This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.

I haven’t read the article (yet) but I came to the same conclusion many years ago.

In a recent previous thread here on HN I was roundly criticised for saying that due-date driven management is not effective, but that’s what scrum has become, and todays thread is exactly what I was thinking about.

My experience in a few businesses is that Scrum as it is generally practiced in industry has been an absolute disaster for productivity. Kanban is awesome because it doesn’t force us to spend hours and hours every week on ceremonies which don’t change the outcome one whit.

In my own business, after 2+ years of scrum - including hiring a CSM - I tossed out our entire process, and replaced it with backlog management and kanban boards. The only thing we kept was the (short) daily standup.

Productivity went through the roof for a number of reasons, not least of which was that because we could now spend the ceremony time working on actual code.

The killer is that if you try to tell people this, they think you’re inexperienced or did scrum wrong or you don’t know what you’re talking about. But to me Scrum is a two year black hole of stagnant product development that I will never get back.

Re: Eight points for one team is two points for another team

#53
One thing I like to do is try to get all stories to be (approximately / more or less) the same size.

I.e., split and gather work so that you don't need to score them. Then you can still get some rough feel for capacity without the bother of sizing.

And if you do this, you shouldn't split hairs and be dogmatic.

Re: Eight points for one team is two points for another team

#55

This is so true. I've been on teams that did 100x work with like 3 engineers. I've also been on teams that do near 0x work with over 10. What I can confidently state is that you must work the people and then the process to improve anything. We need to stop adopting things just because other teams use them or because they are an "industry norm". If we just truly kept true to the original agile manifesto, there would b…

Could not agree more.

Upper management think Scrum is the only way to do software engineering. It’s a management cult.

Re: Eight points for one team is two points for another team

#56
post #37

Earlier quoted context omitted.

> Whatever Agile was Has it changed? The Manifesto[1] is still there, unmodified, to provide thoughts on what you need to consider if you are going to run a software project without managers. > Fuck user stories, fuck sprints, fuck Jira, and fuck product management That does not sound like Aglie, especially given that you specifically call out managers, which are incongruent with Agile. The top-down organization wher…

Look, when a job req goes out and it says "experience with Agile development methodologies" what it means is "experience doing Scrum with Jira". The Manifesto has sweet fuck all to do with what is meant when companies say Agile.

When a job requirement says "20 years experience in Rust", we know that businesses make things up. On HN, however, we can talk about reality, not what is made up for advertising purposes.

Re: Eight points for one team is two points for another team

#57

Earlier quoted context omitted.

> Whatever Agile was Has it changed? The Manifesto[1] is still there, unmodified, to provide thoughts on what you need to consider if you are going to run a software project without managers. > Fuck user stories, fuck sprints, fuck Jira, and fuck product management That does not sound like Aglie, especially given that you specifically call out managers, which are incongruent with Agile. The top-down organization wher…

That is Agile of the noumenal realm. You will never meet it, just as you will never sit upon the Platonic ideal of a chair. Agile, if one deals with it, is Agile-in-the-wild. Compare the original teachings of a religious leader with what you find in the followers. Ah, but you could say, "That's not Agile's fault that people don't live up to it," but in a sense, it is, because Agile did not bother to anticipate that p…

> "That's not Agile's fault that people don't live up to it,"

"Not living up to Agile" is one of its principals: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." That's not what we're talking about, though.

> Agile did not bother to anticipate that people would fall off of the path.

This isn't a case of falling off the path, it's a case of not even being on the same planet. Agile is written about the things you need to think about if developers don't have managers overseeing a project. The OP was talking about what managers are doing. They are at completely different ends of the spectrum.

If you want to use a religious analogy, this is like there being a religious leader preaching about God and a group of people who believe God doesn't exist. Logically, you wouldn't lump them together. They would be seen as distinct groups with opposing thoughts. Exactly how we treat this situation in a religious context: For example, Christianity and atheism.

Re: Eight points for one team is two points for another team

#58
post #12

This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.

Not debating about estimating or not. I'm only replying to the example: CPUs can only execute, what the instructions tell them to do—like a production line—and not solve / create something (new).

Not sure why you were down-voted, but this is a good point. In fact, it is the base problem of all software methodologies. Planning depends on knowing how long an activity will take. Estimating is most reliable when you are estimating something you've already done before. Unless you're working in just such a low-novelty environment, your results will not be predictable and you should understand that the backlog is a priority-ordered list and velocity will let you give a "forecast".

Kanban doesn't "fix" this -- it just changes the frame through which deadline-buzzards get to look at it.

Re: Eight points for one team is two points for another team

#59
post #2

Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…

Here's one to add onto your list: pair/mob programming is bosses weaponizing employees against each other to "prevent goofing off". I've started to form a belief[0] that large software projects in general are A Bad Idea. Whatever it is, if it requires more than a handful of people to build, it's probably for the greater good of everyone--the workers involved, the users, humanity in general, anyone-not-identifying-as-…

I agree with most of this. I’ve done some stupidly complex things using microservices, and I’ve come to similar conclusions - that there are few or no cases where you need a huge monolith, and it’s much better to have small teams working on small tools. Once you get things working at this level, everything becomes easier.

Setting aside the Linux kernel, this is how Unix itself works, and one of the reasons it was successful.

I don’t agree that we should shut down all the “1x” developers though. I think everyone deserves to love their work and people will excel when given the chance. But throwing them against a massive monolith that takes years to understand is dead certain to make them feel stupid and go slow.

Re: Eight points for one team is two points for another team

#60

This post is starting to fill up with what sounds like a kind of hopelessness mixed with anger against Agile. It's possible to do sprints, pointing, demos, and retros well, but you have to own it as the engineering team. This means understanding and adapting the process to your needs. Agree on your definition of done. Set boundaries for pointing. Prevent confusing or unfinished stories from being point. Communicate h…

"Just demand the respect that the business isn't giving you. What's the worst that could happen?" You didn't say exactly that, but that's kind of the undertone of what you wrote. If you live in the US and you demand your right to a fair trial, well good on you. But if you live somewhere perhaps less committed to such a thing, making the demand doesn't mean anything other than you're naive and foolish. So it goes in s…

Sure, if you rephrase my remarks and change my geography you can certainly change the meaning of what I said.
Post reply on HN