Live data from Hacker News

Eight points for one team is two points for another team

lloydatkinson.net

61–70 of 105 posts

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

#61

Earlier quoted context omitted.

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

Yes. I don't really think that anyone should be artificially prevented from doing the work they want to do. But that said, most of the work that people are engaged in is just a complete waste of time. And that's mostly because Large Corporations are the ones telling them to do it.

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

#62

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…

When there is so much overhead in process, the process is a waste of time. Management needs to skill up.

Oh management absolutely needs to skill up. One of the major reasons Agile annoys engineers is because the process is owned by an individual who doesn't understand why they're doing it, or how it can be changed.

Personally, I've found retros to be most important area for a manager to focus. They can be a wonderful source of discussion and improvement for the team, or one of the most boring hours of your week.

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

#63
The funniest agile system I've worked under was with a totally incompetent manager who graded us on number of tickets. Despite supposedly having a technical background he knew almost nothing about software engineering, and didn't care to learn, but needed to feel some sort of control so he would count up tickets each week and berate anyone who hadn't done enough.

Once I got over the initial horror it actually worked out pretty well. I would keep a stack of trivial work on standby for any time I needed to show some board progress and then used the majority of my time to dig into whatever work looked most interesting.

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

#64

> “Building the wrong thing on time and within budget doesn’t buy you much.” Let's get one elephant out of the room out right away. Many in the #NoEstimates camp are speaking from the position of some enterprise context where the business technically has already built the right thing, they have revenue, aren't innovating much (by design), and as long as they keep the ship afloat and don't make too much of a mess of t…

> all of which means nothing if you're not estimating

It also means nothing if all your estimates are so totally wrong and not based in reality, as I mentioned a few times in the bullet points.

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

#65
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…

Your anger sounds directed at the dysfunction within your organization. In particular if you hate product management then you've clearly ended up in a bad place. A good product manager is a joy, someone who is a partner to the engineering team instead of an antagonist.

I don't believe this is true. Having any separation between engineering and product is a defect in the organization. I think the best you could argue is that it's a necessary defect, since it is too rare to find someone who can do the engineering and also keep a perspective on the product. I would argue the opposite, hiring engineers who can't make smart product decisions is like dealing with a shortage of bus drivers by splitting up working the steering wheel and working the pedals into separate jobs. There is some kind of rational thinking behind a strategy like that but it is obviously doomed to be a disaster. Hiring PMs is less obviously stupid, but just as inevitably it is a disaster. If you don't agree, I'm afraid you are like someone who has been on fire their entire life, who will calmly explain how being on fire is fine, and really it's a benefit especially on chilly days. If you ever had the chance to not be on fire for 5 minutes you would stop defending it.

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

#66
post #36
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…

Big A Agile is what happened after management consultants got hold of little a agile and its manifesto. Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.

Author here, yes, I fully agree about all you said especially certifications and dogma. How can you have a certification, in something that is a list of half a dozen goals? By getting a certification in something else, that isn't Agile!

> managing people instead of about satisfying customers.

I wrote another article that somewhat alludes to this, it's linked at the start of this one. If I'm not helping people, either customers, or developers by making their jobs easier, then what exactly am I doing as a professional?

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

#67
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…

Agile was never good. Agile is a marketing word used to sell useless training to even more useless managers.

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

#68

"points" are just a way to avoid being held accountable. If we were to use hours (even buckets of hours, aka: 1, 2, 4, 8 hrs) we'd be better off. It'd be more transparent and while it may differ between team members, we can hold people to account who over / under deliver based on their estimations. The entire point is to estimate velocity (supposedly), so why not have a feedback mechanism that's let engineers learn t…

That sounds wildly micro-managey. I often don't know how long something is going to take until I dig into it; sometimes I don't know how long something is going to take until I'm almost done. The ambiguity/fuzziness of points is a feature, not a bug. If I'm going to be "held to account" based on my estimates, I will optimize for producing work that matches my (naive, uninformed, up-front) estimate, rather than produc…

True. But on the other hand an experienced developer usually can give a reasonable estimate. An if he says: "about two days maybe a week" then that is you best estimate. Using story points is just another complication.

And points do not stop anyone from holding you to account, if that is what they want to do.

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

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

Author here, I too have never seen it mean anything else either. Occasionally replace Jira with Azure DevOps at some places, but overall yes the sentiment is the same.

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

#70
post #36
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…

Big A Agile is what happened after management consultants got hold of little a agile and its manifesto. Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.

I came to think that the whole Big A Agile and small a agile is also just an excuse to put the blame elsewhere.

We can't say with a straight face that we expected IBM or Accenture like conpanies to move to an "agile" process.

And smal and/or smart conpanies were already doing "agile" without making manifesto and boasting it at every occasion. What's left is the middle ground wh

'll blindly follow any trend and get certifications to proudly have the buzzwords on their company site, and "agile" weren't for them either.

Post reply on HN