October 13, 2020
by: Najib Radzuan
What Does it Mean to Be Geographically Distributed? If the developers, IT operations and primary stakeholders are all situated in the same workspace, the team is considered to be co-located. Otherwise, the team is either dispersed geographically or divided in any way. They can work in different buildings within the same geographical area (maybe the team is spread over different office buildings in the same city or some people work from home. For simplicity’s sake, this covers teams that are either geographically dispersed or that have team members that are geographically dispersed. We can divide into three categories below:
- Co-located. Teams where the developers are working side by side in a single room also called a “war room,” “box” or “tiger team office.”
- Near-located. All team members are within acceptable driving distance (e.g. if it would be feasible for all to meet at a single location each day if necessary).
- Far-located. Any or more people are far enough away to potentially need to take a flight to physically meet with other team members.
In this article, we will focus on the far-located team doing DevOps adoption, which I’m currently experiencing. You will also gain insight on how to succeed in DevOps adoption in a dispersed organization.
The DevOps concept emerged to bridge the disconnect between the development and IT Operation teams, it also helps the deployment of product into production within distributed organizations. DevOps is not about the destination, it’s about a journey, or some said it’s an odyssey (Don MacVittie), hence DevOps adoption in a geographically dispersed organization is possible if we do it properly. With new technology and ways of working introduced by DevOps, the destination is not a big issue when the organization wants to do DevOps adoption within different time-zone or regional teams.
Advantages of DevOps Adoption in Dispersed Organizations
There are several benefits when the geographically dispersed organization implements DevOps culture and method:
1. Access to a larger pool of skilled people
Many organizations struggle to employ their IT departments exclusively with local people, particularly when unique skills are required like DevOps Engineer, Leader, Manager and etc. Looking out from another side of the country is probably the best solution for the organization. The organization also will gain experienced DevOps human resources since their distributed workers come from different backgrounds and experiences.
2. Lower development costs
On the surface, savings are the result of wage differentials between countries and often even cities within the same country. However, such savings can be easily lost due to increased overhead associated with geographic delivery – you must understand the total cost of ownership (TCO) and not just hourly system costs when estimating cost savings. Cost reductions can still be made, but you must be sufficiently diligent to achieve them.
3. Quicker time to market/production
When the team is diligent enough to obey the “follow the sun” approach, it is given for faster delivery times. The basic idea is that globally dispersed teams will do its work throughout the day, and then turn off the job to a team that is a few time zones away. This team will do some research, then turn it over to the next team.
Challenges of DevOps Adoption in Dispersed Organizations –
The most effective means of communication between two or more people are face-to-face around a shared sketch space, such as a whiteboard or a piece of paper. Naturally, you have to be together in the same place. With the distribution of the data, you begin to rely, as you can see in Figure 5, on less successful communication techniques that provide more consistency. You can not identify body language that includes several important signs of communication if you are not personally aware of them.
As the team is more dispersed, cultural challenges between sites are often increasing. Different cultures have a different work ethic, treat intellectual property differently, have different ideas about commitment, may be less likely to embrace self-organization, have different holidays, different approaches to things, and so on. Something as “simple” as it means when someone says “yes” can be very challenging in practice.
3. Temporal or Time
When people live in various time zones, it is more difficult to locate similar working hours, increasing connectivity difficulties. In order to address these challenges, you will find that you need to create more documentation than you would normally.
6 Steps to Succeed in DevOps Adoption In a Dispersed Organization
1. Agile practise
A successful journey starts with the right people in the right DevOps practice and role with the right skills – and a willingness to collaborate. The Agile method is promoting close collaboration between the team and across team members. Agile is all about quick execution and quick releases. There is no scope of perfection. The basic concept here is that communication and collaboration frequency depends on which stage of development your team is at:
- High at the initial or requirement and implementation level
- Low at the production stage and design stage.
Below the Agile stages and communication frequency for Far-located teams;
The Agile process includes daily Scrum meetings within the dispersed or offshore team and onsite team, hence they have a chance to update or virtually meet frequently between them every day. Sometimes, In-person meetings, visiting the location of the offshore team or welcoming them to your headquarters office are perfect for building confidence, creating bonding and efficiency and learning.
2. Have a buddy program or ambassadors that travel between far-located sites and the onsite office.
Normally the organization has an introduction day for a newcomer to introduce the organization’s product, environment, vision, etc. With geography, time zone, and cultural differences, the best way to promote collaboration between the onsite and far-located teams is the Ambassador and buddy program. Ambassadors are people who regularly travel between sites, often technically senior people or senior business experts, who share information like culture, organization management style and also the technicality of their product between the sub-teams. Ambassadors have short engagements away from their home site, typically a week or two in length and usually, it happens on a quarterly basis, because of the pressures it puts on the people doing the actual traveling. As a result, you’ll have several people flying between sites at any given time on a reasonable rotation schedule. The Ambassador plays an important role to get the team together at the beginning of the onboard far-located team and ensure everyone knows the company objective and maintaining effective collaboration between teams. The Buddy program entails onsite and far-located workers are paired to ensure the culture barrier between onsite and far-located can slowly take away from teams. They have a specific or fixed time to talk about culture and how their daily routine, hence a closer relationship, more focus and motivation to work more frequently.
3. Sprint release plan
This is the first and foremost requirement for building a successful geographically dispersed DevOps team is to lay a proper change or release management process. Humans are resistant to change and thus, laying complete guidelines to undergo change with DevOps is considered very useful. It is a checklist that represents standards as to which apps should be introduced and when they are done. It also acts as a base for tracking progress within the project. Releases can be intermediate deliveries made during the project or final delivery at the end of the project.
4. CI/CD Pipeline
With a shift in mindset, successful DevOps adoption often needs important improvements to be made to technology, such as pre-production automation, testing, release and integration. The CI/CD pipeline is at the core of DevOps as they encourage collaborative and cooperative work. In other words, the value of CI/CD is no longer a question. The benefits of a CI/CD pipeline approach include:
- Developers can stay focused on writing code and monitoring the behavior of the application in production.
- QA workers and product stakeholders have easy access to the latest, or any, version of the system in defined CI/CD stages.
- Product updates are not stressful.
- Logs of all code changes, test, and deployments are available for inspection at any time.
- Rolling back to a previous version in the event of a problem is a routine push-button action.
- A fast feedback loop helps build an organizational culture of learning and responsibility.
An autonomous team entails developers, as well as members of the operational teams, being able to make choices without a complex decision-making process. Teams are able to operate in a supportive environment where there is no scope of discrepancies. Instead of waiting for manual approval for the code to be deployed in the Testing environment, you can rely on a version control system that can be quickly audited. Without the need for a manual sign-off, the team can automate the deployments and speed up the testing cycle. This would also ensure that the team builds quality products in the development process. The concept of self-testing code also allows regular and low-risk deployments. The following Toolchain can help you to achieve an automation approach in a geographically-dispersed DevOps team:
- Team Collaboration – Atlassian Jira, Microsoft Team, Microsoft Office 365, Slack.
- Continuous Development – Azure DevOps, AWS CodeDeploy.
- Continuous Testing – Selenium, Appium, TravisContinuous Integration – Jenkins, TeamCity, Bamboo, GitLab, CircleCi.
- Continuous Deployment – Chef, Puppet, Octopus, Azure DevOps
- Continuous Monitoring – DataDog, New Relic, Nagios, AppDynamic.
Continuous Monitoring also plays an important factor in a geographically DevOps team, since the onsite and far-located team has different regions and remotely meet, the monitoring tools will help them to figure it out when something happens either in infrastructure metric and application abnormally. It also reduces the time needed to address customer feedback. The following are other benefits of continuous monitoring:
- An effective monitoring tool improves system performance and productivity and helps you reduce (or even eliminate) downtime
- You can adequately plan for upgrades and new projects, and better allocate your time and resources.
- You can detect problems — and solve them — before they impact users.
Your monitoring tool can integrate with an alerting tool which helps lay the foundation for your alerting policies, so you can determine who to notify, how to track issues and outcomes, and how to prioritize remediation.
The organization will face numerous obstacles when developing a far-located or geographically dispersed team for DevOps. There may be problems relating to teamwork and coordination or constructing materials that can be replicated through various projects within the organization. One solution proposed by the industry or DevOps experts in the establishment of the Centre of Enablement the coordination of teams and processes. A DevOps strategy and team structure have something to achieve from implementations in the long run. Any organization will have a strong start if they succeed in bringing more collaboration in different positions and a sense of shared responsibility in order to derive more quality in their deliverables.