Yvo van ZeeThere was a bit of silence from my side, but that was because I had a small sabbatical and was switching jobs. I can personally advise everyone to take a small sabbatical once in a while to spend time with their loved ones. But that is for a later story.
Back in the saddle, I started with a new assignment. Very excited to get started as a cloud consultant in a cloud center of enablement (CCoE) in a big and famous Dutch company. The company itself was already in the cloud, multiple, to be honest, all managed by a well-oiled cloud platform engineering team. Two spiffy landing zones, one AWS control tower with customizations, and one for that other cloud. Everything is automated, a dream of every cloud engineer.
Within the company, there are many teams. A couple of them which are running workloads in production inside the clouds. These were the early adopters and had already started even when the company itself was not finished with all the guidelines on security and so on.
With a new set of goals for the organization on short (migrate), middle (modernize), and long-term (optimize), it is time for the CCoE to enable the rest of the company in its cloud journey.
During the short-term goal of emptying a data center and moving to a DevOps way of working, the company is a bit at a standstill. Teams find it hard to start in the cloud. This is twofold, as from a migration perspective, the teams have to migrate to a new technology, the cloud, and to a new way of working, DevOps. Where back in the day, people didn’t have to think about server specs, maintenance, and running costs, that was for the data center team. But now, they need a budget and think about resilience, security, and all other kinds of topics, which is a bit too much. So, from the cloud center of enablement, we are helping the teams in their cloud journey. And one of the things we help with is agreements. With shifting responsibilities, it is always good to have a clear view of who is responsible for what. So, I often pin down so-called team agreements.
A team agreement is a set of shared guidelines, principles, and expectations that define how the team will work together effectively. It helps the team to align on best practices, how to collaborate, and how to communicate. I often divide it into the following sections.
Roles and Responsibilities: Clearly define who is responsible for what tasks, such as code deployment, infrastructure management, monitoring, and release management. But also on who is leading the standup and who does stakeholder management.
Communication Protocols: Agree on how and when team members will communicate, such as preferred tools (Slack, Jira, etc.), what kind of work framework (Kanban, Scrum), the frequency of meetings, and protocols for urgent issues. When is it allowed to contact who?
Code Review and Quality Standards: It is also important to set expectations around code reviews, pair programming, and standards for coding practices (e.g., naming conventions, testing). Who is allowed to approve changes? The four-eye principle.
Branching and Merging Strategy: Define the branching strategy to follow (Gitflow, trunk-based development) and the process for code merging and resolving conflicts. Never force!
CI/CD Pipelines: As we are changing to a DevOps way of working, the power of CI/CD needs to be explained thoroughly. So, outline the expectations for continuous integration and continuous deployment, including what automated tests or security checks need to be run before deployment.
Monitoring and Incident Response: Without observability, you are basically fishing in the dark. Agree on monitoring strategies (e.g., logs, dashboards) and outline a playbook for incident response, including escalation paths and on-call rotations. Moving to a DevOps way means you build it, you run it, you own it
Collaboration with Other Teams: Define how the team will collaborate with other departments like QA, Security, or Product Management.
Feedback and Continuous Improvement: Encourage a culture of continuous feedback, retrospectives, and learning, fostering improvements in both processes and technology.
When everything has been discussed, written down, and approved by the team, it is time to sign the agreement (in blood) by everyone. With the agreement in place, everyone’s nose is pointing in the same direction, and the actual fun and work can start.
Conclusion.
When starting on a cloud journey, it is not just about adopting new technologies but also about adopting new ways of working. The shift to DevOps, with its emphasis on automation, ownership, and collaboration, can be overwhelming for teams new to the cloud. This is where a clear team agreement becomes invaluable. By outlining roles, responsibilities, communication protocols, and operational practices, it helps teams align, adapt, and succeed in this transformation. As we continue enabling the teams in their cloud migration, fostering clarity and accountability will be key to unlocking the true potential of the cloud and making this journey a collaborative, empowered experience for everyone involved.
