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

111–120 of 138 posts

Re: Principles for product velocity

#111

Post by mwigdahl »

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 is very true, and I second the importance of long tenure. There is no substitute for it; it helps with product experience, personal relationships, and organizational knowledge.

Re: Principles for product velocity

#112

Post by GuB-42 »

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…

> Well, right from the Agile manifesto

The Agile manifesto is great. It is simple, straightforward, and most importantly, it clearly defines itself as a statement of opinion, with a counterpart to each of its value. And yet so many people do exactly what the manifesto tells them not do to. Why? Just why? It is as if a clothing brand has "beach and sun over mountain and snow" as its value and people go to ski with them and complain that they get cold.

Agile is not on size fits all, sometimes you need comprehensive documentation for instance. In this case, just don't do Agile, the manifesto is really explicit in that it is not the right methodology for you. But for some reason, Agile is fashionable, so you take it anyways and try reshape it into the V-model you should have used in the first place and get the worst of both.

Re: Principles for product velocity

#113

Post by msla »

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…

[flagged]

Re: Principles for product velocity

#114

Post by _heimdall »

lupire wrote: post #79
_heimdall wrote: post #70

Earlier quoted context omitted.

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

Agile Manifesto was invented by consultants / contractors to make better products for their customers at a good price, not by ivory tower engineers building Platonically ideal software.

Sure, I don't disagree there. In context I was replying to a comment about how big tech companies use agile and similar though.

I do agree though, when used in the specific context of consulting it may be a better fit than in a big tech corporation.

Re: Principles for product velocity

#115

Post by marcosdumay »

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…

I can't even imagine how Scrum could ever align with the Agile values for it to be abused and transformed. IMO, that part is impossible, and Scrum was always a "bad-management by the numbers" framework.

Anyway, I've hear phrases like your example since some time around 2001. Agile was practically born with a parasitic consulting market intent on having the one true way to do it, and that way being what middle-managers adept of micro-managing want it to be. In fact, I think those consultants were the ones that pushed the word around, without them we wouldn't even have heard of the manifesto.

That's to say that, yeah, I do agree with your comment, but the actual problem is deeper, and harder to fix. Scrum and bad processes are just symptoms here.

Re: Principles for product velocity

#116

Post by ChrisMarshallNY »

msla wrote: post #113
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…

[flagged]

Sigh ...

Normally, I ignore obvious troll comments, but I do have respect for your expertise, so I'd like to ask for some enlightenment. If I'm wrong, the only way to find out, is to ask how.

Thanks!

Re: Principles for product velocity

#117

Post by marcosdumay »

simultsop wrote: post #77
irjustin wrote: post #32

> Pay vendors to do it Generally I agree with this for 90% of startups. If it's a solved problem, you should not be doing it. Don't reinvent wheels just pick wheels off the street and use them. Then an axel then a frame, etc etc until you've got something that moves because it's literally held together by zipties. The key is that a number of people are willing to pay you for the moving ziptie vehicle because it solve…

The line that surprises me: > Of course, using a vendor has significant upfront costs – these things are usually pretty expensive. It also restricts our freedom a bit. I recall I don't know Rick meme instantly. It is obviously contrary. Always doing something on your own is the most expensive way, in my opinion.

Ouch. I guess you never did one of those "we brought large-software-X, and are in 2/3 of the way to implement it; we just need you to plug you in-house software-Y to it" projects, where you end up reimplementing every single feature from X into Y and make people give-up on the brought software before the vendor finishes installing it or allows you to see the documentation on how to plug anything into it.

Those are so common that I think they are the majoritarian way any large software is brought.

Re: Principles for product velocity

#118

Post by Viliam1234 »

GuB-42 wrote: post #112
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…

> Well, right from the Agile manifesto The Agile manifesto is great. It is simple, straightforward, and most importantly, it clearly defines itself as a statement of opinion, with a counterpart to each of its value. And yet so many people do exactly what the manifesto tells them not do to. Why? Just why? It is as if a clothing brand has "beach and sun over mountain and snow" as its value and people go to ski with the…

> And yet so many people do exactly what the manifesto tells them not do to. Why? Just why?

The manager on the top says "do Agile" because his friends say that this is now the cool thing. The managers on the bottom have no idea what it means, so they do some random thing and call it "Agile", and report job done. The manager on the top is happy and gives them a small bonus.

And as managers circulate across companies, they keep introducing the "random thing we did at my previous job and called it Agile" as the one true Agile, so the whole randomness converges to one specific version (with Jira and long meetings and other stuff).

Re: Principles for product velocity

#120

Post by xivzgrev »

Sounds like this company is small. The processes the author discards have their place. His article more or less sounds like “our customers want a small hole dug, we don’t need to a whole excavator for that - just shovels”.

The reason larger companies write prds, figma mocks, etc is to get alignment across more people that are detached from your individual thing

At a small company you don’t need that. Everyone is working on one main work stream

At larger companies, there’s hundreds or thousands of important projects at one time and lots of supporting teams for those. Everyone has their own shit to worry about and can’t possibly remember all the context on your projects, so you make it clear as possible to quickly bring disassociated people up to speed on why it’s important and what you need from them

It also helps disassociated leadership buy into your ideas. A picture is worth a thousand words.

Post reply on HN