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

121–130 of 138 posts

Re: Principles for product velocity

#121

Post by hinkley »

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…

> Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers

Dude, no. Kick managers out of the retro. The retro is a place for uncomfortable candor between peers, not another place for your manager to hold court. They need to leave the room while you decide what’s a problem, and what is not a problem (yet). Once you have a plan on the table you can bring the boss back in to discuss the redacted summary of the meeting and any proposals that require their assistance.

They didn’t work for you because you’ve done them wrong at every single place. I’ve had to fight twice to do it right, but we won both times via solidarity.

Re: Principles for product velocity

#122

Post by hinkley »

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…

That’s because Scrum is so easy to turn into a management process. It makes more sense to them than all the other forms of Agile combined. So like children reaching for candy instead of vegetables, or who will only eat carrots as a vegetable, you have to work to make them reach for something else, otherwise they will be unhealthy.

Re: Principles for product velocity

#123

Post by pdimitar »

hinkley wrote: post #121
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…

> Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers Dude, no. Kick managers out of the retro. The retro is a place for uncomfortable candor between peers, not another place for your manager to hold court. They need to leave the room while you decide what’s a problem, and what is not a problem (yet). Once you hav…

I haven't "done" anything. They were forced on me.

I get what you're saying and with time I started fighting for something 90% the same as you are describing. But most of the time I had no choice. It was "our way or the highway".

And since I was financially and career-wise extremely stupid for most of my life and career... yeah. I worked with idiots and slave-drivers.

I am looking to finally change that by changing the way I conduct myself. You hiring? Yeah, I didn't make myself an excellent advertisement with my original comment but at least people will know where I stand.

Re: Principles for product velocity

#124

Post by hinkley »

cjfd wrote: post #30
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…

Much of this has, I think, to do with mutuality. If person A and person B need to work together both need to change their preferred way of working to accommodate each other. In larger groups there is a problem if one person gets to decide on too much and does not have to take other people seriously.

And that usually breaks, as another reply said, when the manager of the two people delegates responsibility for the problem getting solved to one of those two people instead of keeping it for themselves.

If you have a boss who cares whether the task gets done, you can’t make excuses about how it violates your moat to have to do it. Shut up and help your coworker. Now. Or you’re on PIP.

The coworker who isn’t getting useful collaboration gets blamed for their soft skills, when it’s the boss’s soft skills that should have reigned over both.

Re: Principles for product velocity

#125

Post by hinkley »

josh-sematic wrote: post #103
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…

Largely agree. Heavy process is a tool to help less skilled people have output more comparable to more skilled people. But it comes at a cost of making more skilled people less productive. If you can hire small numbers of highly skilled people you can accomplish a lot with little process. Sadly at some scale “hire only really skilled people” becomes basically impossible and process needs to be more heavy to account f…

Scrum seems to be more about helping a manager of less skilled/experienced people get more output from them.

As people become more familiar with agile processes in general (we all say we are “doing scrum” but we are also doing more than half of XP - otherwise a scrum doesn’t work at all) those gains diminish and I think among us we can agree they go negative.

Re: Principles for product velocity

#126

Post by hinkley »

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…

> But that is anathema to tech companies

One of the biggest dangers in business is believing your own PR. And yet tech companies do it over, and over, and over again.

Re: Principles for product velocity

#127

Post by [deleted] »

xiphias2 wrote: post #29

I love The Rise of Worse is better, and this sounds just like that: https://www.dreamsongs.com/RiseOfWorseIsBetter.html It doesn't explain _why_ simple implementation is more important than having a simple interface, but it just makes an observation that simple implementation usually wins. In my experiments simple implementation won for velocity, because quite often I need to change small parts in all the implementat…

[deleted]

Re: Principles for product velocity

#128

Post by paulcole »

pdimitar wrote: post #84
paulcole wrote: post #69

Earlier quoted context omitted.

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

Regional work culture is a thing and it took me a long time to start looking outside of that bubble. I was pretty stupid when it comes to work negotiations and people abused that. Secondly, I don't think you'll find many programmers praising Scrum. But, think what you will. I'm absolutely the villain, congratulations, you cracked the code. ¯\_(ツ)_/¯

There are numbers between 0 and 100.

Re: Principles for product velocity

#129

Post by seadan83 »

zimzam wrote: post #94
the_af wrote: post #52

Earlier quoted context omitted.

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

Capital-A Agile is for companies that want the benefits of agile (higher velocity) but don’t want to trust their employees or make any meaningful changes in how the management team operates (micromanagement, committing to rigid feature scopes on rigid schedules). Obviously this doesn’t increase work but companies get to say they are “agile” and the management team gets to keep doing all the counterproductive manageme…

Agile is not there for higher velocity! It is sold to management that way often, but intrinsically - no.

Agile though is meant to reduce waste. In other words, you don't march faster, but are supposed to spend more time marching in the right direction. (I personally loathe agile and find it intrinsically broken.. I just find it kind of funny that a process oriented around dynamic environments is supposed to give predictability and speed, when it gives neither. If anything, a lack of predictability since direction can change)

Re: Principles for product velocity

#130

Post by jdsalaro »

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…

> management is very creative

What you described, I wouldn't accept generally under my definition of creativity.

In order for creativity to be such it must ultimately deliver value; managers "doing their job" in ways which hinder instead of supporting engineers is not creative, it's disruptive.

Post reply on HN