We had a large disconnect between product and engineering. The directors solution was to have mandatory 8 hours of sprint ceremonies a week where we would review the definition of “bug” and “epic”, every week. We also were required to sit in on all team meetings regardless if it was your team. We had two full time scrum masters for a team of six engineers.

I suggested instead engineers get looped earlier into the process with stakeholders. The director said it was a bad idea as we couldn’t possibly hope to understand the business side of things.

Very glad I got out

In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.

In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told what the build. Collectively as a profession we have ceded away many of the things that made software development unique and powerful over the last 10 or so years.

This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it.

I do think SV puts more trust in their engineering teams to produce polished software, whereas other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.

> requiring the engineering staff to do a Socratic-like process to pull tangible requirements out

If you've got good business analysts, this is what they're supposed to be doing.

I think if you have great product people, great business analysts, and great developers, the system of PO-Analyst-Developer can work. The problem is that BAs and product people aren't generally making a ton of money, so the great ones will move on to more lucrative positions, and great developers get bored quickly if they're just given a list of JIRA tickets. So pretty soon, one of the three things breaks down then all hell breaks loose. The product folks don't have a clear business vision. The analysts are soft technically and don't know what questions to ask. The developers are either building a space shuttle when they need a bike, or they don't know how to build the bike in the first place.

On the other hand, I can certainly imagine situations where the requirements aren't "hardcoded" but rather they are flexible and heavily driven by what's feasible and what's hard from the engineering perspective (so they can't be "pulled out" from the product leader), and determining that vision properly requires involvement of engineers and can't [technically can, but the outcomes suck] be prepared by someone else and just handed off to engineering.

Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things.

The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.

Frankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.

Moved from where? It doesn't sound any different that what you'd get in any western country.

Sounds like a big company problem. In most startups anywhere in the world, I would think they would be pressed for cash to just hire software engineers.

Junior engineers and PMs need the software to have a skeletal structure on which they can hang their features. This skeletal structure has to be put together by the lead engineer and lead PM. Usually I see both PMs and engineers churning with bad design when such a clarifying structure is missing or ill-defined or has become broken due to hard pivots in pursuit of business/product-market fit.

I would tweak that just a bit that bad developers just want to be told what to build.

The best engineers I've ever worked with and for were constantly asking "why" and would get incredibly frustrated in this "Product Owner runs the backlog" type of organization.

My past work is Very much this.

Edit: details. Our devops allies itself with management and kept “business secrets” from developers. It was abbhorant to witness. I eventually introduced functionality into the devops tools and openned it to developers and got bullied (2nd edit: by my own team and management, i was soft bullied: silence treatments, secret meetings without me, lies, etc. i was junior. My own confession: i did the work without discussing it with the team after being told “fuck the devs” by a senior.) to quit.

That...is so insightful that I am speechless.

I’ve never considered it from that angle.

Brilliant.

That's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?

My guess is that if developers understood the business, they would understand how simplistic a lot of the business models are, and how much of the profit is derived directly from their skilled labor and yet how much of the profit goes directly towards someone else, and developers would suddenly realize they have leverage because they are essentially the profit model.

Note that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.

Hmm, that is a weird conclusion to draw from the observations.

The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them.

That model is generally far from cooperatives and still has plenty of hierarchy.

Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence here points to a very different direction.

(Cooperatives have been tried, and there are some software companies inside and outside of Silicon Valley that work along similar principles. But by-and-large they aren't the companies eating the world.)

Matt Levine's Money Stuff often harps on the theme of investment banks being run like workers' cooperatives in practice.

I would be interested if you have a few names of software cooperatives (still running or not).

I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.

This book had an interesting take on the subject: https://leanpub.com/developerhegemony

It asked why couldn't development firms be organized like how doctors or lawyers often organize themselves, as partnerships with the PMs, etc like nurses or paralegals.

On a more macro level, doctors and lawyers use regulation to keep the competition at bay.

In some jurisdictions, there are limits that make it harder for outsiders to employ doctors or lawyers and sell their services like you would employ programmers.

(In eg Germany, that even applies to pharmacists.)

Even if they use regulation to limit how many and who is a practitioner, this doesn't give a satisfying answer to why they organize themselves that way and we do not.

Just because anyone can be an engineer, it doesn't follow that we can't form partnerships. I could be wrong, but those doctors and lawyers who are in partnerships don't seem to be using that structure due to lack of employment opportunities under other structures.

Another argument I heard was that partnerships are required in certain fields due to liability concerns so that risk can be contained to individual partners. But this only explains why they must, not why we can't.

> I could be wrong, but those doctors and lawyers who are in partnerships don't seem to be using that structure due to lack of employment opportunities under other structures.

A big part of the regulation of doctors and lawyers is the part that keeps the competition out. Google or your favourite startup can't just train up a few neural networks and start dispensing legal or medical advice; even if that advice was much better than what you'd get from your median human lawyer or doctor.

The organisation into partnerships might be more about who's excluded, than what the people in the club are allowed to do?

You are right about liability concerns playing a role, too. And then there's also tax issues.

> I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.

I agree. I just mention it because the companies that 'eat the world' will be the ones people have heard of. And those are not collectives.

As long as the engineers are replaceable by other engineers, that’s not really leverage. The leverage is the capital to pay the engineers’ salaries and the risk tolerance for the business model possibly failing.

Essentially, developers with substantial domain experience / familiarity with the problem space tend to do what they think is best, instead of following orders.

Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse.

Sample phrases include: "Why did the customer ask for that - it sounds like our planned implementation won't satisfy their goals", or

"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".

>"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".

I don't get it. Can you explain?

Boss owns two companies.

Staff at company A have negotiated a profit share / performance bonus.

Boss directs company A to provide services “below cost” to company B. Company A now has no profit to share; it has been funnelled elsewhere to avoid paying the staff their bonus.

This is a dirty tactic, but I've seen it used... a lot.

It has slimy tax advantages too, for the company.

If you're getting profit sharing, you should be able to see the books, and have controlling shares, too... IMO.

Thats an interesting take. But wouldn't product end up having the same leverage? Or is the goal to divide product and engineering work so that no one person has the complete view of the business?

The product department (of a sizeable software company) generally lacks the technical ability to actually construct a competing product with the business knowledge they have. They understand the business' financials and interface directly with customers, but they don't understand how the product works. Any features or issues end up being proxied through these nontechnical resources. This is why you will hear devs complain loudly about the parasitic product department (or equivalent layer above them) that always just seem to be > getting in the way

However, because developers often don't actually want to interface with customers and just want to build cool tech, and charming socialites are very glad to act as that interface, this usually works. As a secondary effect they (non-intentionally) obfuscate the inner workings of the company from the devs who would otherwise (as the GP points out) realise how much they are being (ab)used and turn the screws on the upper management.

Product folks (generally) can't implement their ideas on their own. Devs can.

Business people love to think that their knowledge is somehow on a plane that others can't approach, but we see how many dumb decisions are made on a daily basis. The business would be comprehensible and steerable to everyone in the company, including the janitor, if education were institutionalized.

I have to admit, its pretty arrogant to think someone can make it through high-level physics, chemistry, mathematics, logic, etc., but can't figure out your business classes. Almost makes me laugh out loud.

So much this. I actually studied a joint course of Engineering and business, which was supposed to be two thirds of the Engineering course, two thirds of the business course. When you put it together the Engineering was still about two thirds of the total, with the business stuff mainly being simple things that took a long time to read. Everyone thought it was unsubstantiated just-so stories (Betamax, five forces, etc), but the point was to know the stories so you could communicate with business people.

If you look at things that are actually hard, nobody keeps you from getting the info. You're just not going to understand that graduate seminar in ergodic theory, though you're welcome to attend.

The reason they keep you from the info is of course you'll see the naked emperor.

Business is super complicated. It's more complicated than science, because it's not science.

Science is "easy" because we can model it, to a degree.

Non-science is so hard that we can't even model it, it's that complicated. So instead we try to voodoo our way around it, rely on simple heuristics, history, etc.

Business isn't really all that complicated. It's just opaque and intersects with other things that are complicated, like finance and law.

But the man who invented 1-800-GOT-JUNK and plastered the phone number on the side of every one of his bins was not some better of Richard Feynman. He understood one thing really well: If you solve a problem, have simple messaging, and unabashedly self-promote you will win.

The lawyers, and accountants, and technologists, will all come and help you with the complicated stuff in exchange for a piece of that mountain of cash.

Business is just dependent on thousands of factors that are fundamentally impossible to control. You can model pretty much every factor of it, individually, but you can't model the whole matrix because some parameters are random and wide (earthquakes, pandemics, etc) and some you cannot account for (were you were born and from whom, what education you get and where, who you can befriend, how your brain works, etc etc).

I think one has to differentiate between "complex" and "complicated". Complex stuff requires Big Brains. Business is not complex, all its processes are simple and fairly well-understood; but it is complicated by the interaction of so many factors.

I think a more correct statement would be that people are complicated, and therefore business is also complicated.

Maybe.

If you have ever been in a relationship, you know how irrational people are: ergo, ability in logic and mathematics plays little role.

Went to MIT in engineering/science, and I would do a mental face-palm when I heard other engineers try to ‘sell’ what they are working on.

It’s the “curse of knowledge” where you forget how to relay ideas because you forget your axioms have been updated but the person you are talking with has not had theirs updated.

This is to say some people (in all fields) can sell ideas, and some can’t. Just as some can do high level mathematics, and some can’t. Those curves overlap in unexpected ways.

Oh yea, I don't mean to say that every single individual can run every single aspect of the business personally. Marketing and social skills are not evenly distributed, but they can all understand it at least, provide input, and have a conversation about it, and I believe, often avoid critical errors.

This goes a little further beyond this point I was making, but I also see collective decision making like this as being more fair. Everyone at the buisness is affected by these decisions, so everyone should share in the decision making process. Natural leaders and experts should become apparent and people will listen to them if they don't attempt to bludgeon them with their credentials.

Eh. A lot of engineers really don't have the social skills to navigate the business situations. Some do, sure, and should be given the opportunity to shine. But I would still say the majority don't.

And what kind of "high level physics" do engineers know? A typical masters track doesn't cover the hard maths like in GR, sounds more arrogant than anything... kind of proving my point ;)

Doesn't this basically argue that "business" is basically the same thing as schmoozing?

You could argue that people are a more complicated system than any software system you would see in a talented shop, and people change in real time.

tbf doing things like GR or QFT is not even required for a graduate degree in physics depending on your field of research

I don't know... We don't assume that people who make it through business classes can figure out engineering either.

That said, I do always try to bring along "business people" in engineering challenges and considerations, for which you don't need a full engineering degree. I do appreciate when I get the same treatment.

It's funny, how that would be one of the major differences between Amazon and other companies I worked for. Only for Supply Chain management and logistics.

Yes! The proliferation and role of "business people" in traditional companies is IMO their defining characteristic. It shows how much or how little a business trusts engineers (and also engineer's "status" within the company, e.g. are they respected and valued or treated as a disposable resource) to run the business as general problem solvers.

The ironic thing about Agile is that it has a cottage industry of "scrum consultants", "scrum masters", project owners, etc. which advocate ostensibly for letting developers self-organize but which also has a vested interest for career and self-preservation reasons in inserting itself above software engineers in the decision making process.

Keep in mind that Agile (using the term loosely) was invented by software consultants who wanted to maximize the value they provided to the business they worked with. It’s a formalization of the ideas to make them more “acceptable” to execs and the decision makers (who care about such things).

When applied to in house engineering teams, it is largely ineffective if it doesn’t come with the same kind of freedom that highly paid software consultants get. This is manifested concretely in how many companies have corrupted agile methodologies by focusing too much on the perfecting practices (or “ceremonies”) rather than focusing on the foundational principles.

I'm convinced that the vast majority of business-y manager types that always trumpet "we have to be more agile" have never read the agile manifesto - specifically the "individuals and interactions over process and tools".

It's regretful that it caught on so well and has (incorrectly) evolved into a concrete process in most places rather than an ideology.

I'm convinced of the same thing. I once had a rather enlightening conversation with an Agile consultant who had never read the manifesto. When I showed him, he said "I'm not sure I agree with this".

I've long imagined a position just above the scrum masters: the scrum lord.

I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.

Click [here] to sign up for my Free Introductory Scrum Lord certification course! Join our hundreds of Certified Scam Lords earning well above industry standard after just 12 months of online training!

(Credit card required. Rebilled at $29.95 per month until cancellation. Minimum period of 12 months. T&Cs apple.)

Why settle for scrum lord when you could be scrum king? Scrum emperor? One day even scrum Pope?

Scrumplestiltskin. He promises to teach you to spin stories into code but then takes credit for your prototype.

God-Emperor of Scrum. The code must flow.

In the grim darkness of the future, there is only Scrum!

Now fly my scrumlings! Bring me their estimates! Eeehehehe

Meh. A real Evil Scrum Lord makes his victims enter the data by themselves into Jira.

Hell no. At least then I know it’s entered in a sensible way. If I let the scrum lord do it it’ll be a mess.

Twice. Once in points after Planning Poker has sized the story -- the second time in hours.

OMG planning poker. Never again.

Value based scrum black belt.

> scrum Pope

his holiness will make his presence known in due time

Somehow I suspect that something like this is at work inside the Vatican.

Pope Scrootus the 1st

I definitely agree with you, but I don't think that's sufficient. I think at larger companies it would be helpful to spend a day or two every quarter having a scrum increment meeting. The SI would let scrum lords and scrum masters plan what experiments would occur during the next quarter.

Isn't that just the Scrum of Scrums meeting, only at higher level perhaps?

I think that's the joke.

It would be like scrum of scrums in LeSS or PIs in SAFe. But instead of focusing on what work would be done, it would focus on how it would be done, and what changes scrum masters would make.

I was trying to expand that the joke is already a reality :D

What you are looking for is RTE; Release Train Engineer

haha wow

suppose I should have guessed there were already layers above and beyond the scrum master

it's like the leaning tower of bullshit

Its turtles all the way up.

Still, at my company I have an even more lofty title. I am the Kanban King...

I appreciate your sense of humor

not sure you're going far enough there. Obviously we need a scrum king to guide our scrum lords as they help our scrum masters transform our organization.

What are the perks that flow from the divine right of scrum kings?

The right to make all your slaves refine user stories for the next forty years, of course.....

The scrum lord spends most his day in his office making spunk charts. The making of spunk charts is an intensely personal task that uniquely suits them for office ownership. There have been cases where two or more scrum lords create spunk charts together but it is more rare.

These are people whose entire job consists of sitting in meetings and firing off emails. They can't conceive that other people do work collaborating outside of a meeting room.

Not just collaborating. Any kind of work.

We plan 8 hours a day of work for developers, but they spend 4 hours in meetings, 2 hours fielding questions and just 2 actually working.

At my job its more like 10-12 hours a day, since you are counted on to do 6-8 hrs of programming despite all the other stuff.

To be fair, I've seen engineers with a similar role.

yep, and thank god. Because I sure as hell dont want to do that as a developer

When I was managing engineers, I would insist that the engineer talk 1:1 to the engineer on the client (or customer) side when doing fixes or feature enhancements that happened to be requested from outside the company. This always caused consternation among scrummasters and product managers, and there always had to be a discussion about it. But it sped things up tremendously, because the engineer could do things like say "well, what if we did this other thing instead, which would give you what you need, and also solve another problem we have". In almost all cases the other engineer was happy to talk to our engineer, and very easy to work with. This needed to be a private conversation as well, so that both parties not need to worry about optics. Preferably phone. Once a scrum-master tried to insist that these conversations take place on a public slack channel so that we could "capture" it! And yes I understand why, but it would have skewed the process into something less effective.

This kind of works fine until you have many customers.

If you have < 5 customers, then this works fine.

If you have > 10,000 customers, then this works fine, because you can rely on analytics.

If you have 100 - 500 customers, then it kind of breaks. You can't rely on analytics because those customers are too important, and you can't rely on 1-1 interaction with engineers because there are too many customers to consult on each change.

I've been the client engineer before, trying to get through the opaque 'solution support' folks to the actual engineers of the product. No dice. We could never get the problem solved and we ended up ditching the product.

When I eventually got an NPS e-mail from them, I gave them a 1, and explained that I couldn't get through to actual engineers so we gave up, and then a solution engineer followed up and apologized and informed me that if there was anything they could do, to let them know.

I never wanted to bang my head against the monitor harder than in that moment.

For anyone like me who had never seen the term "NPS e-mail", this seems to explain it pretty well:

https://www.questionpro.com/blog/nps-email/

(I don't know anything about this company and am not endorsing them, just noting it as a reference.)

NPS stands for Net Promoter Score. It's supposed to get a sense of % favorable - % unfavorable and leaving out the middle.

I've seen this at many companies and its one of my biggest pet peeves. Almost nobody uses it correctly. They don't net anything. They take the average. It's not clear at all why it's any different from any other score. I think most people think its some sort of collection or measurement thing rather than a calculation on the data. I hate it. Reeks of innumeracy.

Not that it really matters if you use average vs. nps...

or you could offer - optional non compulsory - support for recording and transcription to the engineers and pay them overtime to jointly produce a final copy / summary (destroying the materials unless required for compliance) as we used to do.

There’s some value in capturing these conversations for the record. If eg the engineer engaged in these conversations decided to leave, it would preserve the record for the person replacing them.

I do agree that if this process is used to score political points though, then it loses all value. Maybe a compromise is to capture the summary of these conversations somewhere. But honestly if an org has become this political.... I would start looking elsewhere.

> If eg the engineer engaged in these conversations decided to leave, it would preserve the record for the person replacing them.

How many of those recordings are ever played back? None, in my experience.

I was referring primarily to slack conversations. Usually when searching for a unfamiliar service or tool, I first do a slack search, then look at a KB/Wiki, then at code etc.

Public slack threads are pretty great since you can follow the decision making process when solving problems. Great slack threads may even include data on what the author tried/didn’t try etc.

I agree with you that video recordings are for the most part useless. Until we find a way to get high quality automatic transcription of videos and add them to a good search index, they will have limited use.

The idea of capturing ppl's conversations is weird. Details of that work are captured in the project stories and version control commits.

There's a big difference between internal work and external work, where that discussion can matter a lot in antagonistic disputes (in court or outside of it) over whether a particular change (and its consequences) was requested or not, and if so, by whom and when.

In a perfect world yes. But the majority of JIRA stories that I’ve come across often don’t contain complete information. The best, well disciplined folks recognize that they will inevitably forget details and write careful summaries, most people write a few bullet point to satisfy the acceptance criteria for the story.

Slack conversations often contain more data. It’s also easier for me to follow a human conversation than a poorly written summary with many missing details.

> traditional companies that are doing Agile.

Aka "Wagile".

"We have a standup every morning, where you're required to report on how many of your assigned Jira tickets you completed yesterday and get berated for any incomplete ones no matter the cause! No excuses! We've committed to these deadlines and budgets, that you know nothing about having not been consulted on anything."

That’s just the tip of the ice berg... I call it the tyranny of project managers.

When I worked for a large multinational in SF, 100M+ users we operated very much in the “SV” style the article describes.

I got to see how our satellite offices in other parts of the world operate; EVERYTHING was in calendar, work was tracked in 15 minute intervals, meeting about meetings, and follow up meetings after the meeting, and a post mortum after. One project manager for every 3 engineers. Dealing with them I felt like I was looking some sort of Project Managers Gone Wild porn set

Then I moved away from the BA and found out most places are like this, it’s real bad

Just print this FAQ and hang it by your desk.

  FAQ

  Q: What are you working on?
  A: Look at the issue tracker 

  Q: Are you working on X?
  A: Look at the issue tracker

  Q: Are you still working on X?
  A: Look at the issue tracker

  Q: Is X finished?
  A: Look at the issue tracker

  Q: Did QA look at X?
  A: Look at the issue tracker

Basically every single standup, "update", meeting I've ever had with a manager could have been avoided by them looking at the issue tracker beforehand. Which I'm sure they did anyway, since they spend most of their days organizing the board. They just ask you questions to which they already know the answer.

Let A and B ∈ Team. After standup, ask A what B did yesterday, what is B working on today whether or not B is blocked. And viceversa.

Then wait for 30 min, do the same. Then wait 3 hours, do the same.

What will happen? they will forget about it because it is irrelevant to them.

Therefore the scrum ceremonies are just bullshit and a waste of time.

Quod erat demonstrandum. Fuck scrum.

How about “people over process”? Yet we are slaves to Agile Scrum process and procedure.

Double talk.

The reasons behind the creation of Scrum and the reasons behind the adoption of Scrum are different.

Plus, most implementations of Scrum are bullshit. Scrum does not recognize the role of a "project manager". There's the product owner, the scrum master and the development team. That's all.

The scrum master only exists to guarantee the process is followed. The scrum master is just a scrum evangelist, not a real leader.

And product owner and scrum master need to be highly skilled people with a lot of responsibility instead of whoever has nothing better to do at the moment as is so often the case.

I still can’t figure out how line managers and architects fit into a well run scrum environment. Seems they would be losing a lot of power.

Scrum does not formally recognize levels of seniority. All members of the development team have the same role.

You can read the official Scrum guide here, it's a few pages long:

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...

I think Scrum exists only to expand the adoption of Scrum. That is at least the reason behind the role of "Scrum master".

By maximizing adoption, the authors can personally benefit and become rich and famous.

There is a reason why they pay that much, they have trouble finding people comfortable with their insanity. That's also what I think is the real reason behind why the interview processes are so contrived and kafkaesques, they reflect the place.

I think you just described my current employer.

Run! There are a lot of places that yes will pay you less and not have free Lacroix but you will not feel bad working for.

I think the key is whether you consider an engineer a business person. That is what links most of the things in the article: a business person needs to know certain business things to be effective, and so if you're considered a business person you get told things like what the competive landscape is, what the budget is, and so on.

For me, the engineer is actually the only person who can do those business functions properly, if the business is solving new problems (rather than a cash cow). I tolerate people who aren't engineers, because I often can't avoid them, but once you get more than a few of these people in your business, things get awkward for the actual engineers.

I also tend to think of engineering as more than just coding. An essential part of it is communicating. You can't do that without technical skills, there's just so much friction.

Maybe (or not, I didn't think that idea fully yet) it is time to start cutting the software development jobs in two jobs: Technicians and engineers. And maybe it is also time for developers to organize take the lead of their craft.

As a person who was there for the early days of Agile, I just want to say it's sad that's what Agile has become. You're right, of course. But that's not what was meant. Somehow "Individual and interactions over processes and tools" became "individuals, please stop interacting and conform to these processes and tools".

It gets worse. If you're caught in a power grab/political game as a developer, some manager consciously use this to slow you down in comparison to their favorite developer.

I was a developer brought into a team along with codebase. They would allow their own devs to go full SV-style, free. But when it comes to me; "please check with PO, create a jira subtask for this"

> Silicon Valley engineering practices can look very non-Agile to a lot people from traditional companies that are doing Agile.

This is of course because the thing that traditional companies call "Agile" is really just the same business-as-usual top-down manager-controlled garbage software process they've always used but with the cool-sounding name "Agile" slapped on it.

Whereas what SV companies do is much closer to what Agile is really about, regardless of what they call it.

That would give developers too much power and make them non replaceable/interchangeable.

They already aren't replaceable in that sense. It it impossible to open a can of developers and hope to get results straight away or hope nothing gets lost if someone leaves.

If you drop your expectations low enough, then yes, it's possible. It involves a steady churn state and the idea that "it's just how it is".

I was a lead developer on an agile team at a $10B+ 50,000 employee pet store chain for 9 months, and never met the product owner.

All backlog was generated by having two analysts or their boss meet with the product owner, a direct marketing exec, writing down what she wanted, then meet with team to give marching orders.

Being a direct marketing exec, all she cared about was “engagement”, so our product was mainly just feeds of pet advice, tips and tricks along with a game (that the bored analysts played all day).

The app also allowed booking store services such as grooming, vet visits, and boarding. But the implementation of the service bookings was so poor it took over a dozen steps with lengthy spinners for network requests. Our metrics showed less than one third of service booking attempts completed.

I pointed out that since the company was terrified of Amazon, that store services were a key differentiator and margin producer and we could make booking services far faster and easier with some design changes.

The response was, that’s not in our backlog. So next build after completing my work, and helping other devs complete theirs, I worked over a weekend and cached some booking data in the app to eliminate spinners on entry into the booking system.

I proudly showed it to the analysts that Monday and they nearly had heart attacks. That wasn’t in the backlog!

All they cared about was making the product owner happy (she was a teller, apparently) and all my efforts did was make me unpopular with them and their boss.

sold my company to atlassian in 2006. i worked at atlassian for nearly a decade. ran bitbucket for years. ran product at docker after that.

any notion that engineers should not be on customer calls, or driving engineering specs is the opposite of what i would consider the best implementation of agile.

> So I get funny looks when I suggest that engineers should go talk to people in the business, and write design docs.

I've gotten more than funny looks. They get downright mean or irritated, because to them it sounds like you're trying to take their job away.

Remember, these are the people who bring the requirements to the engineers.They have people skills! Can't you understand that? What the hell is wrong with you people?! https://www.youtube.com/watch?v=fcIMIyQnOso

I think it also depends a lot on the type of dev and if they want to take responsibility. I have experienced many devs that just didn’t care about the business and design side of things. “Leave me alone and go talk to the product owner”, was something I gotten quite often. But, to be fair I often also got “We want to be more involved in decision making”.

If you set up the responsibility, power & accountability right. Then the developer will have to care and take responsibility. Otherwise, their deliverable is wrong, and they're out. As simple as that.

Exactly, a lot of devs complain about meetings and just want to code.

> "Product Owners" who are there to give instructions via Jira tickets

A good product owners facilitates the communication between business people and engineers (or designers, or others). They don't dictate instructions, they regularly spend time with business people to understand their needs and what they care about, work with engineers and designers to craft solutions that are the best suited to what the business needs. When the relationship works well engineers are shielded from constant interruptions, and can rely on one person to answer their business questions instead of trying to have discussions between all the stakeholders.

As an engineer I was myself very skeptical of the role in the past but then worked with 2 awesome product owners for a few years and it was a fantastic experience.

Regular practice in other industries don’t need Agile to work fast, be creative, or hold people to account for their work. How is software different in this regard?

I think in a lot of industries the work "speaks for itself" like a creative agency or people producing widgets. For creative work you can walk through the assets produced and everyone can theoretically see that there is value being created. I believe software development gravitates towards heavy processes mostly because it's hard for "decision makers" to accurately gauge good software from bad, or even understand what progress is being made at all.

Having more engineers in decision making positions certainly helps, but I think it boils down to whether the organization is set up for trust.

So true.

Then they don't understand what RAD / SCRUM is for - and I would bet had crappy outcomes before the switch.

This post just made me miss coding so much. I spend basically all my time these days understanding the business. Sometimes I just want to blindly code: create an algorithm to calculate x, make a screen to display y. But those roles don't pay.