I remember my early days as a software developer and how I used to hate the development process. I wished my manager would leave me alone with my code and only worry about the final deliverable. My outlook changed over time as I understood how a defined process could help in streamlining software development. However, I believe that a process applied without consideration for the work culture harms software engineering. Also, if the team does not see the value in following the process, they game around it. Software engineers are particularly notorious for cleverly working around a system. I can say that with confidence because I have done it many times in the past!
With that kind of mentality, it’s not surprising that we avoided any formal engineering processes at Druva for a long time. In fact, it worked quite well when we were still a small team. Because of the size, it was easy to keep everyone on the same page. We used to figure out the process on the fly and immediately communicate it to everyone. After replicating the same actions a couple times, it became the unofficial, non-documented process moving forward.
Things started to fall apart when the team size increased beyond a certain point. Looking back, there were multiple issues that should have raised some flags:
Ultimately, it was clear that we needed some documented development processes in place, but as an engineer, I hated the idea of engaging an external consultant or hiring a person purely to identify and document processes. I believed that the engineering team would also have the same feeling. Besides, I thought that we had some pretty good processes already in place and that we should document and improve on them instead of coming up with something completely new.
With that in mind, we arranged for three brainstorming sessions to come up with the first cut of documented development process:
1) The first session focused on identifying existing processes and any pain points with them.
2) The second session focused on addressing the pain points and improving the processes.
3) The third session, a consolidated outcome of the first two sessions, was presented followed by any final comments.
The entire development team participated in all three sessions. This was necessary because our non-documented processes were stored in everyone’s minds. However, there were other important benefits of having everyone present in these sessions:
Now we repeat this set of three three brainstorming sessions after every major release cycle. Defining development processes is not a one-time exercise. We have only taken a minimum viable approach to process definition and documented only the parts of the processes that are required right now. As we grow, there are more parts and details to add to these processes as well as issues and improvements for implementation.
Interested in being part of this process? Join our team!