DevOps Adoption in Geographically Dispersed Organizations

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 3 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 and this article also gives you insight on how to succeed in DevOps adoption in a dispersed organization.

In A Nutshell

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 vs Challenges

There are several benefits when the geographically dispersed organization implement DevOps culture and method:

ADVANTAGES

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, etc. Looking out from another side of the country is probably the best solution to the organization. The organization also will gain vast experience workers in DevOps since their distributed workers come from different backgrounds and experience, it’s different when only hiring local workers, they cannot gain this type of experience and skills.

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

1. Communication challenges
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.

2. Culture challenges
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 challenges
When people live in various time zones, it is more difficult to locate similar working hours, increasing connectivity difficulties. To address these challenges, you will find that you need to create more documentation than you would normally.

How-To Steps

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 collaborate frequency depends on what stage of development your team 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 Headquarter (HQ) office are perfect for building confidence, creating bonding and efficiency and learning.

2. Have Buddy Program or Ambassadors Travelling Between Far-Located Site and Onsite Office.

Normally the organization has an introduction day or induction day for the newcomer in the company to introduce all about the organization’s product, environments, vision and etc. With geographically, time zone, and culture differences, the best to promote collaboration between the onsite and far-located team introduces 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 on-board far-located team and ensure everyone knows the company objective and to maintain effective collaboration between teams. The Buddy program is each onsite and far-located workers have their pair 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 getting a relationship close between them can make them focus and motivate them to work more frequently.

3: Sprint Release Plan

The first and foremost requirement for building a successful geographically dispersed DevOps team is to lay a proper change or release management process. People are reluctant to change and thus, laying complete guidelines to 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, a successful DevOps team 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 benefit of CI/CD pipeline approach;

• 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.

5. Automation

The idea of an autonomous team is that developers, as well as members of the operational teams, should be 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 that can help you to archive Automation approach in geographical DevOps team;

• Team Collaboration — Atlassian Jira, Microsoft Team, Microsoft Office 365, Slack.
• Continuous Development — Azure DevOps, AWS CodeDeploy.
• Continuous Testing — Selenium, Appium, Travis
• Continuous Integration — Jenkins, TeamCity, Bamboo, GitLab, CircleCi.
• Continuous Deployment — Chef, Puppet, Octopus, Azure DevOps
• Continuous Monitoring — DataDog, New Relic, Nagios, AppDynamic.

6. Monitor
Continuous Monitoring also plays an important factor in geographically DevOps team, since the onsite and far-located team has different region 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 is the other benefit from 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 the 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.

Conclusion
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 and productivity in their deliverables.