[aeruder]

Sad, but I would occasionally use my "unlimited" PTO to take a week off and just get work done. Most of the pain started when we transitioned to a sprints from a lack of process. In theory, this was to make things faster (which actually most of the reasons we were so slow was unrelated to process). My week suddenly went from getting things done to:

- 60 minute meetings fighting over whether tickets were 3 or 5 story points

- turning our entire process into some kind of perverse waterfall method where stories involved days of prep work defining every step so that we could accurately estimate story points (I thought this was the opposite of agile?)

- offers to "help" from project managers and managers when things took longer than expected - this help took the form of additional meetings.

- absolute inflexibility over my noon standup. I could be in the deepest of zones and people would literally slack repeatedly until you showed up for that thing

Cue the "oh you were doing <X> wrong!!" people. Modern software practice sucks. Its fine for small bugs and very well defined tasks. Outside of that it is just interruptions, interruptions, interruptions.

I also ended up just quitting. New place is better, but still in many ways the same. At least here I don't have comparisons made to my old days of the pre-software-process productivity.

[icedchai]

Were you playing planning poker? The 3 or 5 story points is something I've definitely experienced.

Standups are okay, but they have to really be focused. Too often I see people dragging the standup into a side discussion instead of handling it off line. I also don't think they need to be daily. Twice a week is enough.

The real problem is micro management. Breaking everything down into bite sized ("2 or 3 point" chunks) is incredibly tedious. In the old days, estimates were less granular. "Joe, we need you to build X. Can you do that in 3 weeks? It also needs to handle blah."

[frankgrecojr]

I can personally relate to:

- 60 minute meetings fighting over whether tickets were 3 or 5 story points

- absolute inflexibility over my noon standup. I could be in the deepest of zones and people would literally slack repeatedly until you showed up for that thing

[curious_cat_163]

I wonder what you make of Shape Up: https://basecamp.com/shapeup/webbook

[humanwhosits]

I've never worked anywhere with story-points, but reading about it now sounds like a metric that will be abused the moment there's any meaning or consequence behind it

[horsawlarway]

I've worked at several companies that use points.

My take away is this: For the most part - treat them like a game of "whose line is it anyways": https://youtu.be/9KAGwNtI26w?t=17

But you roughly need to understand what the company is trying to do - namely: Someone has a job to pick features that we know customers want, and they've been tasked to provide the most value as quickly as possible.

This means someone has to try to guess roughly how long it will take for a feature to materialize, and weigh that against the value it will provide to customers (and then the company - since we're paid by customers).

It's a shit job, but as long as it's clear that teams will screw it up, and that point velocity DOES NOT continually increase over time (unless devs are lying), and everyone understands why they're getting asked - it can be a reasonably productive way to lay out timelines.

[frankgrecojr]

From my experience, it only works if the entire company is completely bought in to the entire system. Even going so far as the SAFe framework. Companies think they can pick/choose which pieces they implement and this is a recipe for failure.

[closeparen]

Don't think I've ever disagreed more passionately with an HN comment. Being "bought in" to agile development means individuals over processes, teams pick and choose what works for them. Insisting that everyone everywhere goes all the way on the same predefined process is as far away as it gets.

[frankgrecojr]

> teams pick and choose what works for them.

Is this practical though. An engineering team has a product team, a sales team that needs a feature. If those 3 teams don't align on the fact that the dev team is practicing "agile" and can expect potential drastic changes to customer promises, then they'll be issues.

[q7xvh97o2pDhNrh]

<soapbox>

Sorry, but I have to tear into this.

The sales team does not need a feature. The sales team needs to convince a customer to sign -- and then to stay a happy customer and refer others.

The product-management team also does not need a "feature"; they need to identify which of the customer's problems the org can solve to get the customer to sign, stay, and refer.

It's the job of engineering to write clean, maintainable code that gets the customer to do those things in an ethical way. That's it. By this metric, they should write as little code as possible -- preferably none at all.

The whole point of agile (without the scare-quotes, without the branding) is that human beings have conversations about the business' needs (both the customer's and the seller's), continuously uncovering more and more information -- and working together to transform that information into a solution.

If the customer's org -- or the seller's org -- managed to make it for 3 months without needing to change a planned feature, that's equivalent to saying that they failed to learn anything for 3 months. That would be pretty worrying.

The issue happens, as you rightfully note, when everyone in the company suddenly decides they're qualified to be engineers -- and they start deciding what features need to be built to solve business problems. That then turns the actual engineers into assembly-line workers who are simply there to blindly build those features.

In a healthy org, we recognize that the job of sales is to build relationships and gather information; the job of product-management is to translate that raw information into clearly-articulated problem statements and get buy-in across stakeholders and customers; and the job of engineering is to decide how to solve those business problems.

And, yes, as part of that, the questions that engineers ask may well ripple all the way back to changing the problem statement itself. That is why engineering, product-management, marketing, and sales all need to work together to build a great product.

</soapbox>

[frankgrecojr]

I love this soapbox! I'm trying to figure out why a well-intentioned company starts this way, and then quickly digresses. I think part of the issue is the feedback loop doesn't exist. If your end to end cycle is done, the sales team can tell the customer that feature x will be done on date y (we can say they should never gives dates but I think this is impractical). Then, let's say priorities change, and the agile cycle determines that we should focus on other items. I think product and sales fail to "bubble this up" and then a toxic culture starts to brew where product and sales despise engineering and middle management can't be trusted to "fight for their engineers".

[frankgrecojr]

Also, I think if we normalized what we both mean by "is completely bought in" we'd be closer to agreeing ;) Perhaps what I meant by this is an understanding that team x is following methodology y and can expect i, j, k because of it.

[markandrewj]

I am not saying you are doing <X> wrong, but I am always amazed how many mangers want to do Agile, and at the same time don't understand that means not doing waterfall. They are completely different methodologies.

https://www.atlassian.com/agile/project-management/project-m...

Also your scrum master should be sheltering you from some of the distractions you are describing.

[frankgrecojr]

> Also your scrum master should be sheltering you from some of the distractions you are describing.

Yes. However, they're usually spread so thin and "scrum master" may too many teams to fully be invested in a single one.

[iamevn]

> offers to "help" from project managers and managers when things took longer than expected - this help took the form of additional meetings.

I hate this one so much. It felt like I got blindsided the first time it happened to me.