[thimp]

I’ve seen agile done well once. Yes it does happen. The process was not described, spoken of or even considered. It just existed between a few like minded decent engineers.

Their manager got an “agile PM” forced on them and it broke.

The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.

[hkt]

Exactly the same thing here. Once some interloper with paper qualifications and no tech background rocks up and says "this is how agile works!" you're doomed.

The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anything, just made sure everyone got heard and that decisions got made. He was patient enough to wait and not force the issues, too.

[praptak]

Organisations make it very hard to be that manager. On top of the human tendency to overmanage there's often push from top for "more visibility and accountability" which results in forcing stuff rather than facilitating.

[hkt]

Blame Mckinsey and their ilk: "what can be measured can be managed".

(I refuse to utter the above phrase without accompanying it with tjis: "not everything that counts can be counted")

[thimp]

It's worse than that. Any sufficiently motivated person can phrase data any way they choose, particularly when their bonus is tied to it. Nor does the consumer of the data always validate that data. I've never seen a manager read a report they requested. That is on top of your suffix which I agree with a well.

[nothercastle]

Not everyone deserves a voice in every conversation. We had an office assistant once’s that had really strong opinions about how to implement features. They were not well informed.

[Scubabear68]

The charlatans are a serious problem in software engineering today.

[gitfan86]

The good news is that it is easy for engineers to start their own companies and keep these people out at first at least.

You will still get cold emails and LinkedIn messages from these people but you don't have to respond

[thimp]

It's somewhat more difficult to start their own companies and eat though which is why a lot of us eat shit and work with project managers.

[whstl]

I also had perfectly operating squads crumble to dust because of PMs, more than once.

I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.

[nothercastle]

I honestly don’t understand how teams in large companies operate without pms. In the initial 5 man design phase sure skip them but when it need 10 groups to deliver some small change that they give zero fucks about the pm is there to keep everyone annoyed enough to do their job.

[whstl]

It works easily without PMs if you have engineering managers and product owners.

[DrNosferatu]

Quality engineering has to be *repeatable*.

If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX.

I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.

[thimp]

I think that's a vast simplification. It doesn't have to be repeatable at all. Objectively repeatability is about elimination of waste and expenditure. The big one is qualification and testing because that's what filters all the crap out. Actually I've worked as an engineer where we had to throw 20% of the products we built out because they didn't pass qualification.

And of course that is where the cost savings are usually made because it is seen as a null function in some businesses. It creates waste and reduces delivery and ROI. Those are all symptoms of other problems in the business but that's how it is generally perceived. And sometimes clients are happy to receive muck if it's cheap.

But that's also how we get planes that crash and Microsoft firing their entire QA and delivering shit for the last half a decade.

And that in turn is because management and project management culture is data driven by people who have no idea what the fuck they are doing whatsoever.

[EchoChamberMan]

I once had to explain to a manager of hundreds of people why reproducibility in engineering (and science) is important. Not good.

[bruce343434]

What has been, in your experience, a repeatable process for quality engineering? How much does it depend on the kind of software one is engineering, or is it applicable to any kind of software with any kind of constraints?

[EchoChamberMan]

Repeatable processes require long term strategy.

[edit] Too many of these people want tomatos, so they plant a tomato, when really they want seasonal tomatos, and need to consider a farm, and take into account growth cycles. The term I like is "sustainable development."

[bruce343434]

I was hoping for more actionable, or at least concrete, advice...

[EchoChamberMan]

Some complexity is irreducible.

As mentioned by user "phkahler":

> 1) Come to work.

> 2) Look at the current state.

> 3) Decide what the product needs from you.

> 4) Do that.

> 5) Use git.

> Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).

> This is how my current job works and we are unbelievably productive.

[edit]

I like the book "phoenix project," and I think they wrote "Team Topologies" which I am curious to read.

[edit]

In general, psychological safety was the number one factor for productive teams, according to a massive google study. From this viewpoint, it's easy to see why there are so few productive teams, as there is little to no safety for most people. Remember though, "There are no silver bullets."

[Edit]

The goal should be continuous delivery imo.