5 ms·

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 sk

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 the tech industry, these days). So good management is critical. Keeping staff for long periods of time is also critical. If you have a lot of turnover, you need process to regulate the churn. Long-term employees don’t need to be told what to do, in triplicate, every day. They Just Know, and that “tribal knowledge” is the real key. Also, people that have worked together for a long time have significantly reduced communication overhead. A lot of stuff doesn’t need to be said or written down. This goes double, when working at scale. All that said, I used to work for a corporation that treated Process as a religion. They make really, really good stuff (at scale), but the overhead can be unbearable. They still make good stuff, though, and I haven’t seen anything close, come from less process-driven outfits. Their competitors have just as much process. I wrote a piece called “Concrete Galoshes”[0], some time ago, that talks about this. [0] https://littlegreenviper.com/concrete-galoshes/ https://littlegreenviper.com/concrete-galoshes/

bantunes 2y ago
That's the thing all these "easy bake recipe for success" blog posts miss: it's all about the people. I've been in companies with the exact same processes and wildly different outcomes because staff was more competent (which includes soft skills) and experienced. But that is anathema to tech companies that think having the right X (agile, Spotify guilds, kanban, etc.) will fix everything because that's what they sell to end users.
- sirwhinesalot 2y ago
  These rigid processes and ceremonies are the mcdonalds approach. You can get a group of unskilled randos and produce passable slop (e.g. MS Teams). The problem is that people with actual skill suffocate in such an environment. If you have a crappy team and only light processes, you get garbage. If you have a crappy team and heavy processes, you get barely passable results. If you have a good team and only light processes, you get great results. If you have a good team and heavy processes, you get barely passable results.
  - ChrisMarshallNY 2y ago
    I was extremely fortunate, and managed a team of really experienced and good developers. Unfortunately, the company I worked for, worshipped Process, so, as their manager, I spent a great deal of time, shielding them from that overhead. This did not always win me praise from my managers. But we got pretty damn good work done. Sadly, it was "engine" code, and was often shipped in "passable" UX. Kind of like dropping an F1 engine into a beater Chevy Vega.
  - kraftman 2y ago
    It's worth bearing in mind that as much as we don't like it, a lot of the time the goal is passable slop. Mcdonalds is doing well, and they arent focussing on increasing the quality of their slop unless theres some public outcry.
    - ChrisMarshallNY 2y ago
      This is true. I once read a comment, here, that said, "If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much." I think that sort of sums up the zeitgeist. I'm also not a fan of the MVP Model. I don't think it results in good work.
      - kraftman 2y ago
        maybe it should be prepended with 'if you work in the mcdonalds of software development companies'
- _heimdall 2y ago
  That does raise the question of what those tech companies' motivation really are though. The processes you described would work really well if the goal is to meet a hiring target and ship just enough product that marketing and sales can run with it. If they don't necessarily care about quality of end product or quality of the engineering that went into, throwing heavy process at the team may get them there just fine. That heavy process may even work better for them if the goal is more managerial control to meet sales and marketing deadlines.
  - lupire 2y ago
    Agile Manifesto was invented by consultants / contractors to make better products for their customers at a good price, not by ivory tower engineers building Platonically ideal software.
    - _heimdall 2y ago
      Sure, I don't disagree there. In context I was replying to a comment about how big tech companies use agile and similar though. I do agree though, when used in the specific context of consulting it may be a better fit than in a big tech corporation.
- hinkley 2y ago
  > But that is anathema to tech companies One of the biggest dangers in business is believing your own PR. And yet tech companies do it over, and over, and over again.
the_af 2y ago
> In my experience, to successfully reduce process, you need to have really good people. Yes, but... Don't all of these Agile methodologies predicate their success on having at least a decent proportion of really good people (including stakeholders!) in the team?
- ChrisMarshallNY 2y ago
  Real Agile, yes (look at the pedigrees of the signatories on The Manifesto). In my experience, modern SV companies are obsessed with hiring armies of short-term, barely-qualified LeetCoders. They sell dross. It would be a problem, if people didn't buy it, but people don't seem to mind, paying for crap. I worked for a company that did really good (and expensive) stuff. They are struggling, these days.
bradley13 2y ago
This. If you have good people, it really doesn't matter what process you use. If you don't have good people, well, it really doesn't matter then, either...
josh-sematic 2y ago
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.
- hinkley 2y ago
  Scrum seems to be more about helping a manager of less skilled/experienced people get more output from them. As people become more familiar with agile processes in general (we all say we are “doing scrum” but we are also doing more than half of XP - otherwise a scrum doesn’t work at all) those gains diminish and I think among us we can agree they go negative.
mwigdahl 2y ago
This is very true, and I second the importance of long tenure. There is no substitute for it; it helps with product experience, personal relationships, and organizational knowledge.
msla 2y ago
[flagged]
- ChrisMarshallNY 2y ago
  Sigh ... Normally, I ignore obvious troll comments, but I do have respect for your expertise, so I'd like to ask for some enlightenment. If I'm wrong, the only way to find out, is to ask how. Thanks!

bantunes 2y ago

That's the thing all these "easy bake recipe for success" blog posts miss: it's all about the people. I've been in companies with the exact same processes and wildly different outcomes because staff was more competent (which includes soft skills) and experienced. But that is anathema to tech companies that think having the right X (agile, Spotify guilds, kanban, etc.) will fix everything because that's what they sell to end users.

sirwhinesalot 2y ago
These rigid processes and ceremonies are the mcdonalds approach. You can get a group of unskilled randos and produce passable slop (e.g. MS Teams). The problem is that people with actual skill suffocate in such an environment. If you have a crappy team and only light processes, you get garbage. If you have a crappy team and heavy processes, you get barely passable results. If you have a good team and only light processes, you get great results. If you have a good team and heavy processes, you get barely passable results.
- ChrisMarshallNY 2y ago
  I was extremely fortunate, and managed a team of really experienced and good developers. Unfortunately, the company I worked for, worshipped Process, so, as their manager, I spent a great deal of time, shielding them from that overhead. This did not always win me praise from my managers. But we got pretty damn good work done. Sadly, it was "engine" code, and was often shipped in "passable" UX. Kind of like dropping an F1 engine into a beater Chevy Vega.
- kraftman 2y ago
  It's worth bearing in mind that as much as we don't like it, a lot of the time the goal is passable slop. Mcdonalds is doing well, and they arent focussing on increasing the quality of their slop unless theres some public outcry.
  - ChrisMarshallNY 2y ago
    This is true. I once read a comment, here, that said, "If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much." I think that sort of sums up the zeitgeist. I'm also not a fan of the MVP Model. I don't think it results in good work.
    - kraftman 2y ago
      maybe it should be prepended with 'if you work in the mcdonalds of software development companies'
_heimdall 2y ago
That does raise the question of what those tech companies' motivation really are though. The processes you described would work really well if the goal is to meet a hiring target and ship just enough product that marketing and sales can run with it. If they don't necessarily care about quality of end product or quality of the engineering that went into, throwing heavy process at the team may get them there just fine. That heavy process may even work better for them if the goal is more managerial control to meet sales and marketing deadlines.
- lupire 2y ago
  Agile Manifesto was invented by consultants / contractors to make better products for their customers at a good price, not by ivory tower engineers building Platonically ideal software.
  - _heimdall 2y ago
    Sure, I don't disagree there. In context I was replying to a comment about how big tech companies use agile and similar though. I do agree though, when used in the specific context of consulting it may be a better fit than in a big tech corporation.
hinkley 2y ago
> But that is anathema to tech companies One of the biggest dangers in business is believing your own PR. And yet tech companies do it over, and over, and over again.

the_af 2y ago

> In my experience, to successfully reduce process, you need to have really good people. Yes, but... Don't all of these Agile methodologies predicate their success on having at least a decent proportion of really good people (including stakeholders!) in the team?

ChrisMarshallNY 2y ago
Real Agile, yes (look at the pedigrees of the signatories on The Manifesto). In my experience, modern SV companies are obsessed with hiring armies of short-term, barely-qualified LeetCoders. They sell dross. It would be a problem, if people didn't buy it, but people don't seem to mind, paying for crap. I worked for a company that did really good (and expensive) stuff. They are struggling, these days.

bradley13 2y ago

This. If you have good people, it really doesn't matter what process you use. If you don't have good people, well, it really doesn't matter then, either...

josh-sematic 2y ago

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.

hinkley 2y ago
Scrum seems to be more about helping a manager of less skilled/experienced people get more output from them. As people become more familiar with agile processes in general (we all say we are “doing scrum” but we are also doing more than half of XP - otherwise a scrum doesn’t work at all) those gains diminish and I think among us we can agree they go negative.

mwigdahl 2y ago

This is very true, and I second the importance of long tenure. There is no substitute for it; it helps with product experience, personal relationships, and organizational knowledge.

msla 2y ago

[flagged]

ChrisMarshallNY 2y ago
Sigh ... Normally, I ignore obvious troll comments, but I do have respect for your expertise, so I'd like to ask for some enlightenment. If I'm wrong, the only way to find out, is to ask how. Thanks!