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

71–80 of 138 posts

Re: Principles for product velocity

#71

Post by kraftman »

ChrisMarshallNY wrote: post #67
kraftman wrote: post #62

Earlier quoted context omitted.

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.

maybe it should be prepended with 'if you work in the mcdonalds of software development companies'

Re: Principles for product velocity

#72

Post by ChrisMarshallNY »

the_af wrote: post #64
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?

Real Agile, yes (look at the pedigrees of the signatories on The Manifesto).

In my experience, modern SV companies are obsessed with hiring armies of short-term, barely-qualified LeetCoders.

They sell dross. It would be a problem, if people didn't buy it, but people don't seem to mind, paying for crap.

I worked for a company that did really good (and expensive) stuff.

They are struggling, these days.

Re: Principles for product velocity

#73

Post by Brajeshwar »

My friends and I believe these are more people-problem than anything else. If we iterate at solving that people-problem as much as possible; introduction of patterns, processes, etc., will eventually lead to better work results.

For instance, even if a team has the best-intentioned tools such as Project Management, CRM, Wiki, Documentation, etc., if the teams do not use them well, they are always bad tools.

Separating toolings (including all of the methodologies) from the ways and the culture of how a team works will be more beneficial to the team and, hence, benefit the company.

Re: Principles for product velocity

#75

Post by brainzap »

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 observed. Why do we keep going in cycle?

I think because there are lots of different type of humans.

The motivated developer. The descipline strict developer. The unfocused. The learner. The over the line stepper who wants more. etc

One process can not serve them all.

Re: Principles for product velocity

#76

Post by jpswade »

Here we go again. The golden rule I've come to realise is that people don't like what they don't understand. It's made very clear this person doesn't like methodologies.

I don't get the use of midwit meme here. Either you're implying that you're preaching the the choir, in which case it's just an echo chamber, or you're calling your audience idiots. Neither outcome is great.

There's always a balance. Being overly orthodox about methodology is suboptimal, yet equally, having no guard rails when people need them is equally as bad. Going around expecting everyone to work exactly how you work is not the reality and tends to lead you down one path.

Re: Principles for product velocity

#77

Post by simultsop »

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.

Re: Principles for product velocity

#78

Post by lupire »

pdimitar wrote: post #43
pflenker wrote: post #31

Earlier quoted context omitted.

Agile and Scrum was great when it was introduced bottom-up and then accepted top-down. "We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together. The Daily was fantastic because it was lightweight and short, but very frequent, so that com…

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…

No methodology will get good work out of bad people.

Having good people is table stakes.

Re: Principles for product velocity

#79

Post by lupire »

_heimdall wrote: post #70
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…

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.

Re: Principles for product velocity

#80

Post by schnable »

> Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?

This sounds like the Six Week Cycles and "Fixed time, variable scope" from Shape Up: https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-varia...

Post reply on HN