3 ms·

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"

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

Jtsummers 8y ago
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.
- petermcneeley 8y ago
  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.

Jtsummers 8y ago

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.

petermcneeley 8y ago
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.