The thing is, every organization has processes. Most just don't write them down (or what they wrote down isn't what they do).
When someone checks code into your master branch, do you let anyone do it? Do you do peer reviews (of some sort)? Do you first run tests? Those are your process. If you don't record them (via documentation or automation) then they're learned by word-of-mouth and can easily be miscommunicated.
Do you have a process (and this is more critical for larger organizations) for purchasing? A lot of tracking here has to do with legal and regulatory compliance, not just tracking for the sake of tracking (at least, for the company, the things being complied with may be worthless to you). Is this written down anywhere? Is it automated in some fashion? Who would you contact if you need to buy a new <something> for your office? What if you need more office space, how would you go about getting it? How does your office track reimbursement for work travel?
I agree that there there is an informal process that we call the culture. The smaller the org the less explicit process required. I dont know about "purchasing" but I do know software so let me address that.
The good SEs that I have worked with knew when to get reviews and when to run what tests. The good SEs tried their best not to harm others and knew when they were exceeding their bounds of authority. This was communicated via cultural transfer and mentorship.
The reason process tends to be bad is that tends to be cumbersome, inhuman, and ridged.
"The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.""
There's process and Process. Big-P process is broken, it's too rigid and turns into quicksand. Or it's not what you do.
But processes happen everywhere, and even good developers aren't going to be uniform in what they do or have experienced. This is why I still find myself teaching 20-year programming veterans about make or *nix, because they've never used it in the past. With many of our more recent projects shifting to git (versus SVN or TFS for our historical projects), we've also introduced new workflows that people aren't used to. We can either have dozens of inconistently styled branches on the main repo, or we can establish a protocol/workflow. Once it's established we have to communicate it. The choice is: by "culture", which is loose, ad hoc, and often ineffective as people move in and out of teams; by process, document what that workflow is.
The follow up to that: If that process becomes Process (seemingly fixed for all time), you've lost. You should reexamine your processes as time goes on to make sure they're still correct, or that they actually accomplish what you wanted. Maybe a part of the workflow was to deal with a particular technological limitation that's since been removed, then change that workflow. But letting it go by word-of-mouth is not going to scale beyond small teams and small projects.
I totally agree about process vs Process. And I dont know who would every really be to opposed to process as guides or how tos. I am a huge fan of self-process and having my own coherent Confluence pages on how to do things and setups and FAQs.
The only thing I would say is that the word of mouth can work quite well still even in large spaces due to hierarchy. If someone on your team doesnt know how to setup a repo and there is no process It is likely the leads responsibility to convey this information.
Of course. But by "process," I think we all understand "defined process." If it's not defined and enforced, it's left to whim and chance. I wouldn't really call that process.
When someone checks code into your master branch, do you let anyone do it? Do you do peer reviews (of some sort)? Do you first run tests? Those are your process. If you don't record them (via documentation or automation) then they're learned by word-of-mouth and can easily be miscommunicated.
Do you have a process (and this is more critical for larger organizations) for purchasing? A lot of tracking here has to do with legal and regulatory compliance, not just tracking for the sake of tracking (at least, for the company, the things being complied with may be worthless to you). Is this written down anywhere? Is it automated in some fashion? Who would you contact if you need to buy a new <something> for your office? What if you need more office space, how would you go about getting it? How does your office track reimbursement for work travel?