Working agreement of the software development team

When a new team and project starts there are a lot of things that should be agreed together. There are general practicalities and as well technical things which are affecting the team's daily work. This article focuses more on technical things that should be agreed upon as a team before the team starts coding.

What is the team's working agreement and why do you need it?

The team's working agreement contains jointly agreed guidelines on how we work as a team and what kind of processes we utilize during the software development. The main focus of the working agreement is to build and strengthen the team's culture and create a unified way of working. A unified way of working in this context means processes and as well as technical things which align the coding. A unified way of working aims especially to increase quality, productivity, and scaling benefits. When this framework is set up it will help to scale and on-board new people to the team more easily.

Team's working agreement

Every team has its own way of working and this article describes one suggestion about what things you should agree on. A working agreement is not something that will be set in stone and then you can forget it. The team should check the working agreement's state every now and then in the spirit of continuous improvement. The team should agree on how and when the way of working related things should be evaluated. Especially retrospectives are good moments for that evaluation.

This article has had a lot of influence from my recent experience when we agreed on these things together with a new product development team. The article presents 6 main principles at a high level of what we agreed.

#1 Agree operational model

The operational model determines how the team structures the daily work routines. Multiple factors align the selection of the operation model ex. people, nature of the project/product, and stakeholders. The operational model is usually based on Agile frameworks (Scrum, Kanban, etc.) but it can be waterfall as well.

The operation model aims for the team to have a common way of working that is transparent, supportive, iterative, and encourages knowledge sharing & continuous improvement. The operational model is one part of creating team culture. 

#2 Agree technology stack

Each member of the team has different kinds of technology-related skills & points of interest so it's important to recognize them at a team level. Technology maturity assessment is one tool to evaluate the current skills of the team. Assessment can be a survey that has a list of different kinds of technologies and scales. Technology maturity assessment is an important tool if team members don't know each other's skills and interests before.

Jointly agreed technology stack of the team aligns daily work but it's also kind of a communication tool to other teams and people in the organization. The team's preferred technology stack must be also compatible with the company's high-level guidelines (Enterprise architecture) to verify that everything works smoothly in the big picture. It's important to frequently discuss the team technology stack and evaluate is up-to-date or not.  

#3 Agree on reference architecture

A team is usually working with one piece of the big puzzle where all pieces are tightly or loosely coupled. From the architecture point of view, it's important to ensure that our piece fits nicely into the puzzle. System architecture (=one piece in the puzzle) must be adaptable, scalable, fault-tolerant, jointly agreed and understandable for all team members. There is no point in fancy architecture which is not understandable for all. Jointly agreed technology stack provides tools to fulfill architecture requirements. 

Reference architecture aims that all components owned by the team are built using jointly agreed principles and rules. Typically reference architecture contains multiple levels like:

• Cloud architecture and governance
• Integration and API architecture
• Data Architecture
• Internal application architecture 

#4 Agree preferred way to produce code

After agreeing operational model, technology stack, and reference architecture it's important to concentrate on more details that are related to producing code. Jointly agreed coding guidelines and processes are aiming to increase quality, productivity, code readability, and maintainability. 

Definition of Done is a tool that determines jointly agreed standards and requirements that must be filled so that individual user stories or bugs can be marked as done. Each team should determine their own definition of done. 

The definition of done can contain technical as well as more process-related requirements. Defined definition of done can look like this:

• Acceptance criteria are filled
• Functionality tests are passed and tested by other than the developer
• Unit or integration tests have been created
• Code is peer-reviewed and follows jointly agreed standards
• Infrastructure is created with code
• Deployment is automatized with the DevOps pipeline and the pipeline is created with YAML
• Monitoring and alerts are configured for the solution
• Implementation is documented

#5 Agree delivery strategy

Delivery strategy determines how the team delivers new versions of the application using automation to the production and what kind of DevOps practices are used to fill all quality and security requirements.

Typically changes can be delivered to production in continuously or in specified release cycles like two times a month. Continuous delivery means that changes are updated to the production with high frequency even multiple times per day. Continuous delivery enables better risk management because changes are smaller and changes are deployed often so the team gets feedback in the early stage. 

#6 Agree on how to ensure operational excellence in production

Every team wants to keep customers and stakeholders happy so the team must ensure that the production environment is working all the time. It's a fact that every system sometimes has unexpected error situations and the team has to be ready for those situations. The working agreement should determine tools and patterns for how the team ensures operational excellence in production.

Typically this means that the team determines a mechanism to monitor application/service availability and enable alerts about unexpected errors. 

Have a nice journey!