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

Principles for product velocity

ssoready.com

Post reply on HN
Print view View original

61–70 of 138 posts

Re: Principles for product velocity

#61

Post by the_af »

f1shy wrote: post #34
alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

What is BS is a fixed, one size fits all methodology. As fast as you write it down and proclaim „this is out procces”, it starts to be BS.

If consultants start selling it as a packaged methodology, you can be certain it's BS.

Re: Principles for product velocity

#62

Post by kraftman »

sirwhinesalot wrote: post #54
bantunes wrote: post #39

Earlier quoted context omitted.

That's the thing all these "easy bake recipe for success" blog posts miss: it's all about the people. I've been in companies with the exact same processes and wildly different outcomes because staff was more competent (which includes soft skills) and experienced. But that is anathema to tech companies that think having the right X (agile, Spotify guilds, kanban, etc.) will fix everything because that's what they sell…

These rigid processes and ceremonies are the mcdonalds approach. You can get a group of unskilled randos and produce passable slop (e.g. MS Teams). The problem is that people with actual skill suffocate in such an environment. If you have a crappy team and only light processes, you get garbage. If you have a crappy team and heavy processes, you get barely passable results. If you have a good team and only light proce…

It's worth bearing in mind that as much as we don't like it, a lot of the time the goal is passable slop. Mcdonalds is doing well, and they arent focussing on increasing the quality of their slop unless theres some public outcry.

Re: Principles for product velocity

#63

Post by pdimitar »

viraptor wrote: post #59
pdimitar wrote: post #43

Earlier quoted context omitted.

Sorry for a bit of a blunt comment following -- but your rose-tinted view of even the original Agile / Scrum ticked me off. I have to push back here, severely so. > The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely. You should qualify your statements with "for me" and "for our project" because dailies have not been a net positive over my 23 years long…

Sounds like you worked in some dysfunctional places. If things worked that bad on the communication/management level, I'm not sure any system really had a chance of working well. If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this. I've never seen a perfect place, but I'm sorry you had experiences l…

> If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this.

Oh, absolutely. Agreed. That's why I left several places during the course of the last 10-ish years.

> I've never seen a perfect place, but I'm sorry you had experiences like that. There really are places which function better and actually do friendly cooperation across levels.

Well, I just recently finished a limited term contract and started looking for a full-time employment (contracting is exhausting). Shout if you have anything. :) I mellowed out quite a lot in the last years and my comment above is just a triggered reaction.

Re: Principles for product velocity

#64

Post by the_af »

ChrisMarshallNY wrote: post #14

Basically, I agree … but … In my experience, to successfully reduce process, you need to have really good people . That usually means a heterogeneous mix of skilled, smart, experienced, and creative people that work well as a team, and teams like that, don’t come easily. People (and teams) are really important, and I believe it’s a mistake to think of them as some kind of interchangeable modules (as is the norm in th…

> In my experience, to successfully reduce process, you need to have really good people.

Yes, but...

Don't all of these Agile methodologies predicate their success on having at least a decent proportion of really good people (including stakeholders!) in the team?

Re: Principles for product velocity

#65

Post by taneq »

alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

> The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology.

Nailed it. “Your heuristic is bullshit, here have a heuristic to know when.”

Re: Principles for product velocity

#66

Post by mcmcmc »

robertlagrant wrote: post #60
baq wrote: post #28

Earlier quoted context omitted.

management is very creative, they just sometimes don't realize that agile is not a management process, it's an engineering process. it's an easy mistake to make because they want to measure engineering output somehow and introduce measurements which cause decoherence of the engineering process state if I may use a quantum analogy instead of a car one. IOW they're trying to do their jobs (manage employees) but enginee…

> agile is not a management process, it's an engineering process That's interesting - I've always thought of it slightly more broadly as a team-running process. You don't have to be doing engineering to do it; you might be building a website in Wix. You just need to iterate and inspect. What do you think?

Maybe it would be more accurate to say agile is a way of doing things, not a way of managing people.

Re: Principles for product velocity

#67

Post by ChrisMarshallNY »

kraftman wrote: post #62
sirwhinesalot wrote: post #54

Earlier quoted context omitted.

These rigid processes and ceremonies are the mcdonalds approach. You can get a group of unskilled randos and produce passable slop (e.g. MS Teams). The problem is that people with actual skill suffocate in such an environment. If you have a crappy team and only light processes, you get garbage. If you have a crappy team and heavy processes, you get barely passable results. If you have a good team and only light proce…

It's worth bearing in mind that as much as we don't like it, a lot of the time the goal is passable slop. Mcdonalds is doing well, and they arent focussing on increasing the quality of their slop unless theres some public outcry.

This is true.

I once read a comment, here, that said, "If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much."

I think that sort of sums up the zeitgeist. I'm also not a fan of the MVP Model. I don't think it results in good work.

Re: Principles for product velocity

#68

Post by bradley13 »

ChrisMarshallNY wrote: post #14

Basically, I agree … but … In my experience, to successfully reduce process, you need to have really good people . That usually means a heterogeneous mix of skilled, smart, experienced, and creative people that work well as a team, and teams like that, don’t come easily. People (and teams) are really important, and I believe it’s a mistake to think of them as some kind of interchangeable modules (as is the norm in th…

This. If you have good people, it really doesn't matter what process you use. If you don't have good people, well, it really doesn't matter then, either...

Re: Principles for product velocity

#69

Post by paulcole »

viraptor wrote: post #59
pdimitar wrote: post #43

Earlier quoted context omitted.

Sorry for a bit of a blunt comment following -- but your rose-tinted view of even the original Agile / Scrum ticked me off. I have to push back here, severely so. > The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely. You should qualify your statements with "for me" and "for our project" because dailies have not been a net positive over my 23 years long…

Sounds like you worked in some dysfunctional places. If things worked that bad on the communication/management level, I'm not sure any system really had a chance of working well. If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this. I've never seen a perfect place, but I'm sorry you had experiences l…

If someone’s work history is littered with only dysfunctional companies, are we sure the companies are 100% of the issue?

Re: Principles for product velocity

#70

Post by _heimdall »

bantunes wrote: post #39
ChrisMarshallNY wrote: post #14

Basically, I agree … but … In my experience, to successfully reduce process, you need to have really good people . That usually means a heterogeneous mix of skilled, smart, experienced, and creative people that work well as a team, and teams like that, don’t come easily. People (and teams) are really important, and I believe it’s a mistake to think of them as some kind of interchangeable modules (as is the norm in th…

That's the thing all these "easy bake recipe for success" blog posts miss: it's all about the people. I've been in companies with the exact same processes and wildly different outcomes because staff was more competent (which includes soft skills) and experienced. But that is anathema to tech companies that think having the right X (agile, Spotify guilds, kanban, etc.) will fix everything because that's what they sell…

That does raise the question of what those tech companies' motivation really are though.

The processes you described would work really well if the goal is to meet a hiring target and ship just enough product that marketing and sales can run with it.

If they don't necessarily care about quality of end product or quality of the engineering that went into, throwing heavy process at the team may get them there just fine. That heavy process may even work better for them if the goal is more managerial control to meet sales and marketing deadlines.

Post reply on HN