By: I'm often confronted with the question about adding process to a small software development team of a Startup. It seems to be a common myth that adding process to a small team hampers the speed and pace at which developers must develop to quickly get a product to market at a startup. That process on a small team takes time away from developers that they could be using to develop the product. That process is a luxury for development once out of the startup phase. This is not only false but can actually lead to missing deadlines, poor quality, poor team moral, and extra resources.
I have been part of development teams at startups with the "Wild West" mentality of each developer focusing on their piece and only communicating when they need something with little to no accountability. These teams always miss deadlines, have a poor product, have frustrated engineers, and managements answers seems to be to through more bodies onto the project. I've also been part of and lead development teams that did incorporate process. The difference is night and day. Process brings projects on schedule, holds them to higher quality, has happy developers, and doesn't require more resources or time then the "Wild West" method.
One of the biggest benefits of process is the ability to plan development to hit deadlines. There are different methods of process, my favorite is Scrum. I won't go into the details of the Scrum process, but it allows flexibility, developer buy-in, accountability, and communication across the team and company. The scrum master, or person responsible for ensuring scrum practices, can easily be a developer on the team. Process will allow management to know very early what the team is capable of, what to expect, and very realistic timelines for milestones.
A product can be pieced together by developers but without process the quality cannot be guaranteed. A QA process is a must even for the smallest teams. Even the most careful developers should not be left as the only QA before a customer sees the product. QA should be built into the development process. If using scrum, then the person responsible for QA should be part of that scrum team to ensure that at the completion of the development cycle the product is in a releasable state. Any QA process should include a QA checklist that is constantly updated and checked each QA cycle.
Good process will allow communication between team members, shield team members from management, encourage team cohesiveness, and reduce frustrations due to a lack of process. Process such as scrum allows developers to be aware of and plan for dependencies and feel ownership of their tasks.
A common complaint against process is that it takes more time to implement process then to just do the work. Or that process takes time away from a developer who could be doing more development. Unfortunately, this is proven time and time again as simply not true. Yes, process does take time, but in the end is saves time. A typical developer on a small team using scrum will spend less then 10 minutes in a daily scrum meeting where all of the necessary communication takes place. This means they're not in hour long design/bug/team/department/company meetings. It also means some kind of task management that requires the developer a few seconds to grab a task, but means that are doing tasks that have been prioritized and deemed important to complete.
Process should never be implemented for the sake of process. And there is the concept of too much process. However, not having process even for a small team in a startup environment can and usually is detrimental to the success of the project.
