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

51–60 of 138 posts

Re: Principles for product velocity

#51

Post by robertlagrant »

foldr wrote: post #35
robertlagrant wrote: post #33

Earlier quoted context omitted.

> e.g. which of 1000 web frameworks should we use? This is fuzzy, but that's because it's not a technical question! It's isomorphic to "what three blog posts on web frameworks did I last read?" (-:

You're right that decisions regarding frameworks are often made for largely arational reasons, but I'm baffled by the claim that these are not technical decisions (unless you're just joking?). If they're not, does that mean that in your model it's the PM who decides which web framework and database the team uses? In any case, even if my example were a bad example for some reason, there are definitely lots of technica…

Oh yes, I agree that there are technical decisions are fuzzy. I'm happy to concede that; just dashed it off too quickly.

Re: Principles for product velocity

#52

Post by the_af »

jdsalaro wrote: post #25
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 problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place. At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand. Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to appl…

> At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.

I think most commenters on HN understand this.

But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades to understand Agile (Scrum et al) can fail just just as often and is as prone to mismanagement and meddling as the methods it was meant to replace.

It takes a strong team (leadership and stakeholders included) to make Agile work and reap its benefits. But such a strong team will probably work well with whatever methodology -- strong teams are effective regardless.

What about average teams, which Agile was supposed to be helping? In my experience, they'll fail just as often.

A method that works for a team of focused superheroes is not really applicable to the general population of developers.

Re: Principles for product velocity

#53

Post by sirwhinesalot »

megamix wrote: post #40

Who does this apply to? Idiot mode doesn't make sense in the long run, does it mean they skip tests? Do they only build fragile stuff? Is there API easy to work with?

Idiot mode just means that if the job is to turn some bits into some other bits, you just write a function to do that. You don't make a whole business taxonomy in a UML class diagram first or worry about the single responsibility of the function or whatever.

Re: Principles for product velocity

#54

Post by sirwhinesalot »

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…

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 processes, you get great results.

If you have a good team and heavy processes, you get barely passable results.

Re: Principles for product velocity

#55

Post by pflenker »

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…

Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere. Reading through my post I do think it's sufficiently obvious, as I am specifically mentioning how I remember certain projects.

Looking through your counterpoints I think I need to emphasise my opening sentence a bit more strongly: It was fantastic _when it was introduced bottom-up_. This is important, because the ceremonies were all engineering-driven and managers usually not present. So there was no rushing and "whipping" during the retros, there was no scrum master being the manager and everyone wanted to be done with the daily quickly, and so on.

> Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.

I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.

> [...] over my 23 years long career.

Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.

Re: Principles for product velocity

#56

Post by ChrisMarshallNY »

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…

I was extremely fortunate, and managed a team of really experienced and good developers.

Unfortunately, the company I worked for, worshipped Process, so, as their manager, I spent a great deal of time, shielding them from that overhead. This did not always win me praise from my managers.

But we got pretty damn good work done. Sadly, it was "engine" code, and was often shipped in "passable" UX.

Kind of like dropping an F1 engine into a beater Chevy Vega.

Re: Principles for product velocity

#57

Post by pdimitar »

pflenker wrote: post #55
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…

Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere. Reading through my post I do think it's sufficiently obvious, as I am specifically mentioning how I remember certain projects. Looking through your counterpoints I think I need to emphasise my opening sentence a bit more strongly: It was fan…

> I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.

Agreed, and apologies for the assumption. I got a little bit pissed, not at you though. :)

> Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.

Oh I know, but I believe both you and I witnessed a lot of similar techniques during our careers. At one point they just figured they'll give them a lot of names.

> Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere.

Yeah I know I was a bit difficult here, my idea was to bring visibility to our different bubbles. I've heard positive stories about Scrum / Agile many times but I am yet to live in one. :(

Re: Principles for product velocity

#58

Post by jvanderbot »

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…

There is no breaking cycles. Humanity is on an approximately periodic 20-year oscillation around the mean. Just look at programming languages, ai cycles, web iterations, etc.

It's just human nature - we deplore the tools our parents used.

However, as long as that mean drifts in the right direction!

Re: Principles for product velocity

#59

Post by viraptor »

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…

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 like that. There really are places which function better and actually do friendly cooperation across levels.

Re: Principles for product velocity

#60

Post by robertlagrant »

baq wrote: post #28
jdsalaro wrote: post #25

Earlier quoted context omitted.

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place. At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand. Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to appl…

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?

Post reply on HN