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

131–138 of 138 posts

Re: Principles for product velocity

#131

Post by philwelch »

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…

> But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight.

Agile is agile the same way the People’s Democratic Republic of Korea is a democracy. And like most dictatorships with these names, I’m sure they also have a founding myth that claims a genuine concern for Democracy and the People.

Software developers are concerned with developing software. The people with the time and energy to develop and sell methodologies like Agile are not in the business of developing software; they’re in the business of selling methodologies. Maybe they’re consultants trying to sell clients on the methodology as a selling point for their consultancy (much of Agile seems geared to this), or maybe they’re trying to train people to be Certified Scrum Masters or whatever. Either way, you can’t actually sell people a methodology that boils down to reducing methodology because then you have nothing to sell.

I know I sound cynical, but the reality is that human behavior is driven by incentives and anyone who genuinely cared about making processes lightweight has little incentive to hang around the Agile scene fighting with the grifters.

Re: Principles for product velocity

#132

Post by pdimitar »

paulcole wrote: post #128
pdimitar wrote: post #84

Earlier quoted context omitted.

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.

Yes, and I never said 100% of my professional experiences were bad. I had extremely positive contracts that left me smiling.

What I did say was that I never stumbled upon managers who did Scrum / Agile in a way that was empowering for the programmers.

Obviously these two things are very different.

Re: Principles for product velocity

#133

Post by meiraleal »

mattm wrote: post #81

The missing context here is that their company looks to be a very small team - 5 employees according to LinkedIn. Any process or methodology, or lack of, will work for a small sized company. At that size you get things done by just talking with each other. That doesn't scale to companies with hundreds or thousands of employees where multiple teams that you've never interacted with before may be involved in a project.…

> These "throw out the processes and methodologies" articles are always written by people at small companies.

That's great advice then! HN is mostly comprised of people looking for tips on how to go from 0 to 1, not to 0 to 100.

Re: Principles for product velocity

#134

Post by tkiolp4 »

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…

Same here. Daily stand ups (no matter if they last 5 min. or 20) have not being useful for me any single time. They are used by managers to force us to show what we have been doing the day before. No more, no less. If I ever get stuck with something, I go and ask for help to my colleagues; I update the corresponding Jira ticket status and whatever is needed to keep my work visible.

Same for retros or any other kind of ceremony. They are just for managers.

Re: Principles for product velocity

#135

Post by alentred »

baxtr wrote: post #105
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 agree, it’s a new/old methodology disguised in a rant. To your last point that we’ve come full circle. Maybe that’s exactly how things evolve. Start small, get large and complex, cut back to become simple again. While it might sound like a circle, I believe that it’s an evolution. Things improve over time with each iteration.

> Maybe that’s exactly how things evolve. Start small, get large and complex, cut back to become simple again.

I like to think it is! Two steps forward, one step back, but overall advancing slowly.

Re: Principles for product velocity

#136

Post by PaulRobinson »

sirwhinesalot wrote: post #99
PaulRobinson wrote: post #82

> Given a standard of quality, what can we ship in 60 days? Others have said it, this is a methodology, and quite an aggressive one that causes a lot of questions to be asked, and if you don't, you'll end up in a mess. It requires planning, discussion, size estimation, design, maybe even prioritization (if you have two things that each take 45 days, one needs cutting and a 15 day one needs picking up, or you need to…

But most software out there is built with heavy processes? SAFe and all that nonsense, and everyone agrees the output is complete garbage. The software that is lauded and praised tends to be made by small teams of highly skilled engineers, stuff like EmberGen. To me what this says is that software is not, at all, like other engineering disciplines. Software developers aren't like masons, we're not just mixing cement,…

I agree the answer is not more process. But the answer is also not “no process, let engineers get on with it”.

We need different processes. We need much better managers. We need to plan, but in ways that are specific to the risks of software development. It means more work, but not, perhaps more meetings.

Re: Principles for product velocity

#137

Post by sirwhinesalot »

PaulRobinson wrote: post #136
sirwhinesalot wrote: post #99

Earlier quoted context omitted.

But most software out there is built with heavy processes? SAFe and all that nonsense, and everyone agrees the output is complete garbage. The software that is lauded and praised tends to be made by small teams of highly skilled engineers, stuff like EmberGen. To me what this says is that software is not, at all, like other engineering disciplines. Software developers aren't like masons, we're not just mixing cement,…

I agree the answer is not more process. But the answer is also not “no process, let engineers get on with it”. We need different processes. We need much better managers. We need to plan, but in ways that are specific to the risks of software development. It means more work, but not, perhaps more meetings.

Oh then we are in total agreement.

Re: Principles for product velocity

#138

Post by Quimoniz »

xiphias2 wrote: post #45
Quimoniz wrote: post #37

Earlier quoted context omitted.

This really hinges on 'velocity': > .. simple implementation won for velocity .. How do you specifically define velocity in this context? (I am asking because I tend to favor speedy velocity in quick iterations; which is another story, than say velocity for change...) Kind regards

Sure, it's the speed of adding a new incremental simple feature to the existing code base.

Thank you.
Post reply on HN