The Worst Process — One That Doesn’t Solve a Problem
What is a process? It is a series of actions or operations conducing to an end.
Every company has a business problem to solve — an end to reach. A process is essential because it keeps people focused and allows continuous improvement, eventually leading to efficiency in solve the business problem.
There are many examples of business processes — Sales to Implementation Process, Hiring Process, Software Development Lifecycle (SLDC), etc. Within R&D, there is quarterly planning process, product launch process, agile software development process (e.g. scrum), etc.
Fellow developers, do you enjoy following processes? Is it helpful?
All these being said, the biggest telltale sign of a bad process is the one that doesn’t solve any problem. Here are the processes I have experienced and I will discuss why they are good or bad:
- Good: scrum process (daily standup, planning and retro), quarterly planning/retro.
- Bad: standardization of operating models for all scrum teams — too prescriptive and the wrong level. (OKR is a better alternative).
- Context-dependent: ORR (Operational Readiness Review) could be a good one if the teams are not mature enough to operate, but counterproductive for experienced teams.
From the list, scrum process and quarterly planning are good processes because they solve the problem of prioritization. Operating model standardization had a goal to provide consistency and transparency to how scrum teams operate. However, in our case, the real problem is the sales Org’s perception that R & D didn’t make much progress. They felt engineerings are only busy running in circles but not progressing. For ORR, it depends because the problem to be solved varies. In one company, the problem might be team’s lack of awareness or motivation to release an operable software. The ORR serves as a forcing function. It has benefit. For another company, the problem might be engineering teams don’t have the tool to properly operate their software, though they have the ability and desire to do it. Having an ORR isn’t as helpful and could be frustrating to the development team. A better investment would be tooling.
Overall, while processes are necessary, it is crucial to clearly state the problems to be solved. When in doubt, err on the side of fewer processes.
