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

101–110 of 138 posts

Re: Principles for product velocity

#101

Post by astrobe_ »

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 wonder how we can break the cycle

"Hire former software engineers at management positions" would be the answer, but of course there are various factors that makes it difficult to do so.

In theory, management should be held accountable for getting in a way, but it is not possible either because of the nature of software development: one cannot really measure productivity because it is to a more-or-less large extent a research activity.

I think probably the best option is to introduce some more democracy (or rather "technocracy" in the literal sense, "power to those who build") in the mix: management evaluated and chosen by the engineers. Call me communist all you want...

Re: Principles for product velocity

#102

Post by sevensor »

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…

Agile, in practice, has turned into "disorganized waterfall." Witness absurdities like the existence of the "Agile Gantt Chart for Jira." The reason Waterfall, or modern Agile, are the way they are, is that they are systems that allows the smallest possible number of people to take responsibility, while allowing everyone to perform accountability. Basically nobody wants to lay it on the line and say to the CTO, "I'm going to make this project succeed." Much easier to say, "we're using best practices and modern processes."

This is a consequence of failing to train managers, especially in the moral dimension of management, which is entirely about accepting responsibility, and of promoting into management individuals who are not prepared to do so.

Re: Principles for product velocity

#103

Post by josh-sematic »

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 for that.

Re: Principles for product velocity

#104

Post by ebiester »

sevensor wrote: post #102
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…

Agile, in practice, has turned into "disorganized waterfall." Witness absurdities like the existence of the "Agile Gantt Chart for Jira." The reason Waterfall, or modern Agile, are the way they are, is that they are systems that allows the smallest possible number of people to take responsibility, while allowing everyone to perform accountability. Basically nobody wants to lay it on the line and say to the CTO, "I'm…

It turns out for large cross-team initiatives, organizing the work is as hard as doing it.

I like the example of internationalization. You need involvement from all parts of the product to release it - you rarely can sell a half-internationalized product. You need to work with external teams of translators who need to be fed the work in a consistent interface. There will be pieces of the work that nobody is going to forsee (e.g. pulling text from the database) that will be surfaced and handled consistently.

So, to get it out, you need to have each team prioritize the work. You effectively need a deadline, or the work will never happen. (The work is valuable for the company, but does not drive any individual team's customers.) You will have dependencies: Team A has to address part of the work before team B can. And you need a way for teams to report that they are done so that it can be reviewed for consistency across the product.

This is a bad fit for most agile methodologies, but you're not going to take everyone out of it temporarily and then go back in. So you have to accommodate a project within your system.

But these exceptions become more and more common as your company gets bigger and bigger. The only truth that I can find is that the only way to stay agile is to stay small: small teams naturally do the things that are agile.

Re: Principles for product velocity

#105

Post by baxtr »

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.

Re: Principles for product velocity

#106

Post by kmacleod »

mooreds wrote: post #98
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 think there's some truth that process slows down development. (Full disclosure, I work for a company in the same space as these folks.) I love a provocative essay as much as the next person. But the authors are in a relatively new, smaller company focusing on devtools[0]. This has a couple of ramifications related to process need: - they are the customer to a great extent, so they don't need to involve external cus…

Every team has process. It doesn't matter if it's documented or not, or whether improvements (or impediments) are intentional or not. Every team has their process.

Source: Identifying teams' principles and practices is one of the tools I use.

Re: Principles for product velocity

#107

Post by commandlinefan »

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.

> we’ve come full circle.

We never went anywhere. I had such high hopes for the agile manifesto when I first read it in 1999. "Whew," I though, "finally, they realize that software can't be managed like an automobile assembly line." Nope, they just rebranded the "manage software like an automobile assembly line" methodology as... AGILE! Don't get me wrong - the signatories on the agile manifesto did seem to understand how to realistically plan and manage software. Nobody else who read it and had any position of authority seemed to.

Re: Principles for product velocity

#108

Post by FrameworkFred »

While I can get behind a lot of points in this post like "what can we do well in 60 days?" and "some problems aren't important," I shudder a little when I see that headline, when I note that the company provides SSO for enterprises, and when I then wonder about their test and QA pipeline.

Re: Principles for product velocity

#109

Post by mwigdahl »

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…

This sounds cynical on its face but it is my experience as well. Management does not actually trust engineers to provide value without close oversight (sometimes with good reason!), so any framework that purports to give engineers more autonomy will eventually be subverted by the management. And since management always has more power than line engineering, they always win.

The only way for "true" agile to really take root would be for management to trust engineering to add more value on their own than when being micromanaged. That's a tall order, and gets much taller in larger organizations.

Post reply on HN