Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Collaboration” is bullshit

joanwestenberg.com

Post reply on HN
Print view View original

111–120 of 193 posts

Re: “Collaboration” is bullshit

#111

Post by parasubvert »

MetaWhirledPeas wrote: post #109
commandlinefan wrote: post #95

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting "the date" is the only thing that's tracked (but it also never happens). It's even justified through vague analogies like Joel Spolsky's admonition that "you wouldn't buy a pair of jeans without knowing how much they cost" without ever doing a slightly deeper d…

> the date is _always_ more important than the actual deliverable. Always. Hah! You just gave me an idea for a new methodology. Date-bound delivery. - The business tells you what they want, as they do - The business tells you when they want it, as they do - The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted. - As the date nears, more edge features get…

that's really what agile was supposed to be. at least in the places where I saw it was successful.

every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design.

every week, priorities can adjust, etc. and the cycle continues. hitting the actual 'release date' becomes much more knowable when you see the tangible date-driven progress on a regular cadence.

Re: “Collaboration” is bullshit

#112

Post by MetaWhirledPeas »

parasubvert wrote: post #111
MetaWhirledPeas wrote: post #109

Earlier quoted context omitted.

> the date is _always_ more important than the actual deliverable. Always. Hah! You just gave me an idea for a new methodology. Date-bound delivery. - The business tells you what they want, as they do - The business tells you when they want it, as they do - The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted. - As the date nears, more edge features get…

that's really what agile was supposed to be. at least in the places where I saw it was successful. every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design. every week, priorities can adjust, etc. and the cycle continues. hitting…

Yes, but expanded to the full deadline instead of only the short iterations.

The business does not care about week long deadlines. They need something on May 23 so they can achieve _______.

My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on making it happen. In other words, usually it doesn't happen.

But date-bound delivery is already our default mode of operation. We just don't like to admit it. We are going to deliver something on this date; we just don't know what, yet.

Re: “Collaboration” is bullshit

#113

Post by msteffen »

kube-system wrote: post #101

The problem isn't "collaboration", the problem is people who don't really know what "collaboration" really means. Status reports, standups, committees, meetings with a large number of people, etc, does not make "collaboration" happen. Collaboration isn't a process or a management technique -- it is a communication style. If you want collaboration, you can't take random people and use process to "make them collaborate…

> Collaboration isn't a process or a management technique -- it is a communication style. If you want collaboration, you can't take random people and use process to "make them collaborate" -- you need to build your team out of people who are collaborators.

Yes! I would add that IMO the communication style can be learned and there are great rewards for doing so.

I believe the rough statistic that 20% of people on a typical project are contributors. I don’t believe that it’s because the other 80% are losers. IME it’s because no serious effort has been made to include them, make sure they understand wtf is going on around them, and help them solve whatever is holding them back.

If you do this, a) it does work, and b) the need for small teams becomes apparent because the now-onboarded person can’t find anything that isn’t already being worked on, so they (with encouragement) start a new thing. And there are limits to people’s ability to understand what’s happening, especially if they’re inexperienced, and some people really don’t have the skills to contribute, but by and large, building bridges for people is still highly worth doing.

Re: “Collaboration” is bullshit

#114

Post by parasubvert »

plagiarist wrote: post #97
jimbokun wrote: post #96

Earlier quoted context omitted.

Standups should eliminate almost all other meetings engineers need to attend. Except to go deeper on questions that came up in standup that cannot be instantly resolved. Otherwise yeah there’s really no point.

I would be pleased with the standup if it eliminated other meetings, but that has definitely not been my experience.

there should be only 3 regular meetings in an agile engineering team - weekly iteration planning (1-2 hours max) - daily standup (15 mins max) - weekly demo & retro (1-2 hours max)

literally everything else is work off the kanban board or backlog.

in my teams everyone was told to decline all meetings unless it explicitly led to the completion of a weekly planned story/task. this way all meetings for the team have a clear agenda and end in mind.

for mandatory external meetings & running interference with external parties, there are ways to insulate the majority of the team from that.

Re: “Collaboration” is bullshit

#115

Post by MadxX79 »

MetaWhirledPeas wrote: post #109
commandlinefan wrote: post #95

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting "the date" is the only thing that's tracked (but it also never happens). It's even justified through vague analogies like Joel Spolsky's admonition that "you wouldn't buy a pair of jeans without knowing how much they cost" without ever doing a slightly deeper d…

> the date is _always_ more important than the actual deliverable. Always. Hah! You just gave me an idea for a new methodology. Date-bound delivery. - The business tells you what they want, as they do - The business tells you when they want it, as they do - The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted. - As the date nears, more edge features get…

That pretty much describes shape up : https://basecamp.com/shapeup

I have a mixed relationship to it, but the scope cutting part of it works extremely well.

The focus it brings on focusing on the problem solved rather than on the concrete solution is also healthy I feel.

Re: “Collaboration” is bullshit

#116

Post by JackFr »

pknomad wrote: post #22
icegreentea2 wrote: post #4

Earlier quoted context omitted.

It's a provocative title, but I think this section better captures his scope of argument - "Collaboration-as-ideology has made ownership and responsibility feel antisocial, which is a hell of a thing, given that ownership is the only mechanism that gets anything across the finish line.", as well as "But there’s a huge difference between communication and collaboration as infrastructure to support individual, high-age…

Yeah, I think the author strays a bit away from the title. The author says, "The collaboration industry has spent a fortune obscuring a dirty truth: most complex, high-quality work is done by individuals or very small groups operating with clear authority and sharp accountability" which means collaboration can work... in the right environment and with the right people. I work in R&D and I could not imagine not workin…

It was also probably never true. The author handwaves away 'disagreement about his methods', but SLA Marshall was also simply a liar. He claimed interviews he never did and lied about his own combat experience and the circumstances of his own commission.

Re: “Collaboration” is bullshit

#117

Post by parasubvert »

MetaWhirledPeas wrote: post #112
parasubvert wrote: post #111

Earlier quoted context omitted.

that's really what agile was supposed to be. at least in the places where I saw it was successful. every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design. every week, priorities can adjust, etc. and the cycle continues. hitting…

Yes, but expanded to the full deadline instead of only the short iterations. The business does not care about week long deadlines. They need something on May 23 so they can achieve _______. My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on maki…

I completely am in favor of date-bound delivery.

However the point of the weekly cadence is that the business does care about adjusting scope and priority towards hitting that deadline on May 23, so that they know what they're going to get on May 23 and have the power to adjust it.

Especially if the goal of what is delivered on that date is not clearly defined. It almost never is.

Most projects can be summed as "give me $X, I'll come back in 6 months, and ask for more time and money". or "here you go"... "that's not what I wanted".

It's a key risk mitigation toward a hard date to know every week if you're still getting what you wanted.

Velocity is overblown as a metric. It's one metric among many that can signal a few things (e.g. quality problems because bug fixes are overtaking features) but isn't as much of a lever as some say.

Re: “Collaboration” is bullshit

#118

Post by red-iron-pine »

gherkinnn wrote: post #36
mb7733 wrote: post #16

I was skeptical about the claim that 80% of soldiers refuse to fire their weapons, so I did a little reading and it seems like the original source has been pretty much debunked. This 2011 article sums it up: https://scholars.wlu.ca/cmh/vol20/iss4/4/ but it's been doubted for decades.

On Killing further develops the idea [0] by looking at a wider set of battles across time and, crucially, finds that by adapting training methods, the kill rate went up to beyond 90%. This then appears to come with higher rates PTSD. 0 - https://en.wikipedia.org/wiki/On_Killing

On Killing also has serious issues with credibility

it relies on SLA Marshall's dubious work, and several other examples it uses are difficult to take seriously.

it's similar to Freud, where there are shreds of truth but not really universally true or applicable.

Re: “Collaboration” is bullshit

#119

Post by MetaWhirledPeas »

parasubvert wrote: post #117
MetaWhirledPeas wrote: post #112

Earlier quoted context omitted.

Yes, but expanded to the full deadline instead of only the short iterations. The business does not care about week long deadlines. They need something on May 23 so they can achieve _______. My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on maki…

I completely am in favor of date-bound delivery. However the point of the weekly cadence is that the business does care about adjusting scope and priority towards hitting that deadline on May 23, so that they know what they're going to get on May 23 and have the power to adjust it. Especially if the goal of what is delivered on that date is not clearly defined. It almost never is. Most projects can be summed as "give…

Yep I agree. Iterations are still good, demos are still good, ever-evolving scope discussions are still good, regardless of the overarching methodology.
Post reply on HN