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

161–170 of 193 posts

Re: “Collaboration” is bullshit

#161

Post by parasubvert »

sunrunner wrote: post #122
parasubvert wrote: post #114

Earlier quoted context omitted.

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

Is that three kinds of regular meetings? Because I count 8 meetings (and four kinds, as I don't think I've ever had demo and retro combined due to different groups of people being in both).

Sure, I was being loose with my terminology, you are right to correct this.

the point was in a 40 hour work week, it's reasonable for 15% of it to spent in coordination meetings, while 85% is directly related to progress.

Usually the retro is after the demo when other folks leave the room / drop from the zoom :-)

Re: “Collaboration” is bullshit

#162

Post by magicalhippo »

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…

> Such a methodology would ensure delivery, but not necessarily the contents of that delivery.

But sometimes/often it doesn't matter that you delivered 70% by the agreed date, since less than say 90% is useless.

We have an upcoming deadline. By a given date, some government system shuts off and another must be used. By then the customers must run functionality tests to prove their software handles the new system.

If all of those tests don't pass it doesn't matter that we got most of them by the shutdown date. Customers won't get access to new system and their production halts, not acceptable.

Scenarios like this is quite common for us.

Re: “Collaboration” is bullshit

#163

Post by ytoawwhra92 »

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…

As others have said, this methodology exists in various forms already.

It has a major practical problem:

> The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted.

If the team doesn't think they can deliver something that the business feels is non-negotiable, the two are at an impasse. The methodology gives no way to resolve this impasse.

And this problem is exacerbated because the business will frequently be wrong about what they want and when they want it by, and the team will frequently be wrong about what's achievable by the given date. And both parties know this, and it starts to affect how they interact with one another when discussing dates and deliverables.

And to make things even more confusing there's often some amount of unacknowledged deception. Sometimes when the date arrives everyone collectively just pretends that the thing has been delivered in full. Because it doesn't actually matter whether it has.

Re: “Collaboration” is bullshit

#166

Post by rvba »

nuancebydefault wrote: post #99

It is true that on an individual level you get more work done if you collaborate less. But very often you will have solved the wrong problem. Collaboration often prevents that from happening because different point of views will make that clear before trying to solve a problem.

Collaboration often means... not solving any problem.

In big orgs there are often people who dont deliver anything at all, so they sabotage those that deliver or try to deliver.

Re: “Collaboration” is bullshit

#167

Post by sage76 »

jimbokun wrote: post #96
plagiarist wrote: post #83

Earlier quoted context omitted.

The standups are also organized around disrupting a small group of people for the convenience of one.

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.

In my last company (before I left tech forever) I would tell my team that I am blocked on something or my progress is slow because of whatever reason and it would all get ignored lol.

It was almost like they required the standup as part of the process but never used it the way it should be used.

Re: “Collaboration” is bullshit

#168

Post by strangattractor »

bombcar wrote: post #127
parasubvert wrote: post #108

Earlier quoted context omitted.

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

The corollary is that it's only the budget that is tracked that anyone cares about. Often your salary is not on that budget, so if it takes you twice as long but you don't have to buy/hire/use AWS, winner.

Salary does not need to be on the budget because it is the same whether you work 40hrs per week or 80.

Re: “Collaboration” is bullshit

#169

Post by tharkun__ »

evilantnie wrote: post #145
youknownothing wrote: post #129

Earlier quoted context omitted.

To me, the _real_ thing that matters isn't quite date or budget, but something that somehow acts as an umbrella to both of them: the promise. When you promise to deliver something by a day, or within a budget, it's very clear whether you met your promise or didn't. However, when it comes to functionalities, there is more of a grey area: you can start to argue that something _mostly_ works, that some bugs are always i…

I feel like everyone in this reply chain is looking at this from a different angle of Fast, Good, Cheap. Pick two.

That was literally the first thing I thought reading from OP comment down to your parent.

Then I thought: Sure but management made the devs promise these things. We don't do it of our own volition (exceptions prove the rule - some people are conditioned to do it of course).

Post reply on HN