Our Software Development Process
Intro
As someone who has worked as a software developer for almost 10 years, I have experience with a variety of different projects, both agile and not. In this article, I want to provide an overview of the software development process used in our team at Julius Baer. I will then conclude with my personal experience.
Past experience
In previous projects I’ve worked on, developers were responsible only for implementing requirements without any interaction with customers. Typically, one or more requirements engineers would gather requirements from customers and pass them on to the developers. Developers would then try to understand the requirements and implement the required functionality. If they had any questions, they would need to go back to the requirements engineers for clarification, who in turn needed to go back to the customers. Unfortunately, this often led to productivity slowdowns, delays in deliverables, and reduced software quality.
Current experience
Scaled Agile Framework
In contrast, at Julius Baer, we have a very different development process. The teams are given the freedom to define their own software development process, and we regularly exchange ideas with each other to continually improve our best practices.
We follow the Scaled Agile Framework (SAFe) methodology, which provides a framework for coordinating and aligning large-scale software development efforts across multiple teams, departments, and even entire organisations, to enable faster delivery of high-quality software products.
Our software development process
For relatively simple features, user stories can be directly created and defined. Each user story has a description of what needs to be implemented and a list of acceptance criteria and technical acceptance criteria. Acceptance criteria are conditions that the delivered software must meet, and should be understandable by users or customers. Technical acceptance criteria are intended for software developers and define how something should be implemented. User stories are then reviewed by at least one other developer and adjusted based on feedback. They are then presented to the team, discussed, and estimated during the refinement sessions.
For more complex features, we create Solution Designs (SD). The purpose of an SD is to document requirements and architectural decisions. The Solution Design typically contains the following sections: Goal, Overview, and Proposed Solution. The Goal section provides a brief description of what needs to be implemented and the business reasons for doing so. The Overview section lists the related user stories and tasks and describes all questions and decisions taken. The Proposed Solution section usually starts with an overview of the proposed architecture, and then describes all changes that need to be implemented. It could, for example, list some new database tables with the column names and types, new REST endpoints to be implemented, and some mockups that show what the final UI would look like.
The people working on the SD will be in continuous dialogue with the Product Owner (PO) and business representatives to collect the requirements, understand the business context, and clarify uncertainties. The direct contact and short feedback loop make the whole requirements gathering process efficient and help the team to gain or deepen their business knowledge.
After having finalised the SD, the user stories will be created, presented to the whole team, and estimated during a refinement session. They will then be prioritised by the PO and planned for subsequent iterations. Once the user stories are implemented, the software engineers will create a pull request to merge their code into the main branch. At this point, one or more code reviews will be done by the other developers. This helps ensure that the code is of good quality and follows our coding standards. After the code review, the Continuous Integration and Continuous Deployment (CI/CD) pipeline will be triggered. This pipeline will build the code, run all unit and integration tests, and deploy the code to the development environment. Once the tests are passed, the new functionality will be available in the development environment for the Product Owner to test. The Product Owner will verify that the functionality meets the acceptance criteria, and if everything is okay, he/she will accept the user story. The user story will then be moved to the staging environment. In the staging environment, we have a few more manual tests that will be done by the QA team. Once everything is verified, the new functionality will be deployed to the production environment.
Summary
In conclusion, our software development process is very streamlined and efficient, thanks to the adoption of the SAFe methodology. By involving the software engineers in the requirements gathering process and giving them the freedom to define their software development process, we have been able to deliver high-quality software on time and on budget. Additionally, the use of Solution Designs, code reviews and automated testing has helped us maintain the quality of the code and the software.
My personal experience
As stated above, I have worked on several different projects and there are significant differences in the approach to software development at Julius Baer compared to my previous experience. The biggest one is that at Julius Baer, the developers do not just get a list of requirements that need to be implemented and delivered, but are actively involved in the requirements gathering phase. They speak directly to the business owners and end users and can better understand their needs. This has the positive effect of being able to gather the business knowledge, which then leads to better software being delivered.
Another difference is that in some of my previous projects, just a few developers used to estimate the user stories. Instead, here the whole team is involved, and this has several advantages. Involving the entire team in estimates leads to more accurate assessments of the effort required. Additionally, it ensures better visibility of upcoming user stories and a shared understanding of the long-term vision.
The last difference that I would like to again highlight is the fact that developers are given the freedom to shape the software development process and that they can contribute their own ideas. This freedom allows us to tailor the development process to our team’s specific needs and it doesn’t force us to follow a predefined process that, in some cases, adds more overhead and reduces motivation.
