In the field of software development, different teams have different approaches to how things are being done. When the team is small, introducing processes may be overwhelming, and the biggest challenge is to determine when is the right time to define one.
From the early days at Things Solver, we didn’t quite think about defining the development process, because things were going quite smooth and onboarding was really fast. Then, over the time, the amount of work to be done has grown enormously, which resulted in trade-offs between the quality of work and delivery time. The assumption that everybody is completing their responsibilities and bringing the most quality to the work is nice and represents a team spirit full of mutual trust and respect – but misunderstandings and lack of experience often lead to unwanted results where something has to be paid off.
That is how we encountered a situation requiring a handover of some part of our application, where the code that was left behind was really unorganized and full of anti-patterns which made it hardly understandable. It resulted in re-working the module which was to be handovered, and our realization of how crucial it is to introduce some standardizations. We needed to make sure that everybody understands what they need to deliver, and to introduce best practices across the whole company. And as all processes are born out of random mistakes, so did ours. We have defined our development process on a company level, so that we all have less “unknown variables” while doing our best work.
The first phase of the process is planning of the roadmap that decides what our long-term plans are for our product. Here we estimate the ruff timeline of our product progress in the following months. After the initial setting of the road map it may adjust and expand at occasional intervals, but changes to the roadmap should not be drastic from the initial setup. When a road map is set up, it should influence the planning and design of specific tasks.
The next phase of the development process is task design. The task design sessions involve the most senior and most experienced members of Things Solver, who together precisely define the requirements that the feature should support and which will be worked on in the coming period. For example, if a task involves a particular microservice, the task design sessions define which endpoints the service supports, what are the endpoint inputs, what logic is applied within the endpoint, and what the outputs of each endpoint will look like.
After this phase, the defined tasks are prioritized based on their complexity and the time required for delivery. When we have defined tasks, we can approach sprint planning. Sprint planning is an event that takes place every two weeks where work tasks are distributed for the next sprint that will last for the next two weeks.
The last phase of the development process is development. It is a period of two weeks between sprint planning in which people work on assigned tasks. During the development all teams have daily meetings where people talk about what they will be working on that day, as well as recap meetings that take place at the end of the working day where everybody talks about their progress, potential problems, blocking or bugs they encountered.
When somebody finishes a task, it is submitted for code review. Peers that are reviewing the code can ask questions, ask for changes or approve the submitted code. When three approvals are reached, the task is considered completed and the next challenge can be started. If all tasks that are distributed in the planning phase are finished the first thing on the backlog is the next assignment.
I hope you enjoyed my quick overview of our development process that we tailored to our company needs and maybe see something that you think you can apply in your work environment.
Photo credits: https://unsplash.com/photos/KE0nC8-58MQ