Introduce software process guide

software_processes/README.md

@@ -0,0 +1,48 @@
+# Template
+
+Software processes can be great, or they can be awful. In order to be successful at clients we often need to influence their processes.
+
+## Conversation starter: client process examples
+
+We've had to deal with suggestions like these at various clients. What do you think of them? Some of them have many different answers
+
+- "We keep having production issues on the weekends. Therefore, we will not deploy on Fridays anymore. Any code we finish that isn't deployed on Thursday has to wait until Monday to be deployed."
+- "We always need to deal with dependabot PRs, and it's unfair for the same people to always be taking responsibility. Therefore every week a different person will be responsible for merging dependabot PRs, and we'll track who is responsible each week using a roster."
+- "We need developers to take responsibility for their work. Therefore, when anyone writes code, they will be responsible for fixing any bugs in that code from that point onwards."
+- "We have many production issues where the frontend and the backend are out of sync. We will schedule our deployments. Every day at 8am all changes on main will be deployed on staging and we will all test there. After that we will deploy everything to production."
+- "We are often surprised by the decisions that have been made for a project when it's very late and there isn't time to fix things. Therefore stakeholders will work with designers at the start of a project. The designs for every project will feed into job stories based on those designs. The stakeholders will review those stories and sign off before development can begin. At the end of the project, every job story will review the project to check that it matches the designs."
+- "We need a QA team, because it is unfair to ask developers to test their own work. There is a natural conflict of interests and we should avoid that."
+- "We are a startup. I can't afford to have three people working on only one thing. Everyone gets their own project."
+
+## Best Practices
+
+We want to encourage processes that generally encourage software fundamentals (of the sort found in Lean, Agile, Devops, SRE, XP like iteration, ownership, "shift-left" etc). We also want to encourage processes that match our thoughtbot values.
+
+Here are some specific ideas that may help with the next time you are evaluating a process.
+
+We like processes that:
+
+- are almost invisible, because many of the best processes are not even considered "process"
+- add something that we wouldn't have without them
+- help people see and act in accordance with the big picture easily when they are focused on the detail
+- are supported by good tools
+- are followed by well-practiced people
+- help us avoid bias
+- bring resources (focus, people, time, energy) to important but neglected areas
+- build ownership
+- improve velocity
+- increase collaboration
+- safely avoid handoffs and gates
+- rely on team trust
+- create consistency in areas that matter
+- help us with tasks we don't do often
+
+We disklike processes that:
+
+- Make us feel afraid
+- Make us do work that could be automated
+- Reduce velocity
+- have a goal that is unclear or can't be evaluated
+- we don't understand
+- are used in the wrong context (e.g. an enterprise process in a startup)
+- take time rather than making time