In general, process shouldn’t be a dirty word, it’s useful in many situations. I’ll start with a little story. When I joined Square there were a set of books that were given as required reading. Old Man and The Sea and The Checklist Manifesto were the two. Checklist Manifesto, I thought, that’s an odd one. But after reading a few lightbulbs went off. The author does a good job spending time looking through different domains where, arguably small, process changes lead to real meaningful improvements in society. For example, surgeons washing their hands and validating / checking basic health information. What is surprising is how much pushback there was for insisting small, and seemingly obvious, parts of the process into the medical profession.

So if it’s understood that introducing process to help save lives is a no-brainer, how do we end up with bad process? What even is bad process? Let’s start with an obvious examples, it’s pretty well understood that the silo’d “hand-off” nature of waterfall development really didn’t work in the software domain (maybe it does for a nuclear plant. So process that creates silo’s is likely bad. But, how should we evaluate process? Here are a few ways I think about effective process.

  • Process should be in service of outcomes, this is one of the key things that Agile gets right. Focus on the riskiest thing, solve that and keep iterating until you’ve met customer expectations.
  • Process should create feedback loops where ones may not exist. This is arguably the most important think about the Toyota Production System, which the Lean Startup methodology, is based on. Anyone on the Toyota production line can stop the whole line, this creates a wonderful incentive, things get fixed. Do the processes we use create the space for feedback from the whole team?
  • Process shouldn’t be linear. Our world and the work we do isn’t linear. So while there are many linear processes (building a widget in a factory) that exist in our world, this doesn’t really apply to software development.
  • Process can be used to reduce variability. This is very useful in say the airline and medical professions. Where is this also useful? Running high SLA production services. This is why we have oncall runbooks, retro’s and deploy processes. However if you’re building a new product, variability is likely your friend.
  • Process is unique to the team and product. This is why it’s really hard to just Do Agile because it’s situation dependent. This means it’s important to think about minimum viable process. The reason that this is important, once process is put in place, it becomes part of the culture, part of the habits and rituals. What do we know about habits? Well they are very hard to change.
  • Process should be iterative! Think about iterating on process, just like you iterate on product. How do you do that? Well, feedback loops are useful. A good tactic here is to have a “Airing of grievances” session between all members of the team, have people write out what’s frustrating and see if you can find threads between the challenges. Sometimes that process, sometimes it’s something else.
  • Finally, a useful heuristic is whenever you add some process, what process are you taking away? Sort of like net-zero process. Obviously you have to start somewhere, but even if there’s no obvious process, it exists in the ways people work.