[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".

[q7xvh97o2pDhNrh]

Thanks! And, yeah, I agree -- it's basically a communication breakdown.

It takes work to continuously bring everyone together to disagree-and-commit over priorities. It's one of the major components of leadership and influence in organizations these days. Ideally, managers are continuously broadcasting information and regularly pulling each other into meetings to have healthy debates.

(An old mentor taught me that timelines are the lowest-common-denominator of communication. When people stop getting useful information and get frustrated, they resort to pushing on timelines, since that's the one common language everyone in the org can speak without needing any other strategic context.)

I think another major contributor is that so many people have never worked at a healthy, well-functioning technology organization. Then, as people bounce around, they bring their habits (and coping skills) with them. Endless hordes of certified scrum-masters team up with non-technical stakeholders to turn engineering teams into coding teams -- and the cycle continues on.

[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.