As enterprises and start-ups look for different ways to fill the developer shortage, many teams include different remote partners This may be on shoring, off shoring, contractors on site, or any variety of different remote team configurations.
Those teams using Agile methods already utilize good collaboration strategies These teams use tighter feedback loops than waterfall or other traditional processes. Along with these great methods for teams to communicate, the teams also need to practice good engineering practices One of those good engineering practices, a repository integration strategy for Remote Teams is essential, and our focus here We are focusing on a strategy using a centralized source code repository.
Code Repository Basics
You must understand code repository basics for the rest of this to make sense Branching discussions assume that you understand branching and merging concepts Dev, Main and Release are branching terms utilized here Refer to documents from your code repository if you need a refresher on these terms The term main branch refers to a stable branch to be utilized for integration testing Later, a main branch would be utilized as the branch to create a release branch Refer to figure 1 as the diagram that illustrates how this might work.
Figure 1 A simple Branching and merging strategy
How Teams Communicate
A good repository integration strategy needs good team communication to work That communication strategy means the team uses mature practices (usually agile practices) to encourage good collaboration Mature teams means the team understands and can teach new team members how to use good practices Mature does not refer to all team members being over the age of 60!
For a detailed explanation of how to implement an overall agile collaborative strategy, view these (shameless plug alert!) articles:
- Getting Started with Scrum Development
- Agile Techniques: Getting Started with Kanban
- Jump in the Waters Fine: Implementing Agile
Below is an overview of some practices mature teams use to help facilitate a good repository strategy.
The teams are practicing sprints of no more than 4 weeks, but usually 1 or 2 week sprints for highly mature teams They may be practicing continuous flow, so the iterations are not used, but they do have a good method for feedback from customer to team.
Also teams must break requirements down into small features By doing this, when remote teams are integrating, these small features allow quick integration These small features can be utilized in communications between teams For instance if Team 1 has completed 2 user stories and is merging up to another branch, this should be communicated to the other teams The communication might be in the form of a multi team meeting, or through a wiki or your ALM tool The team must have rules that define when to merge your stories.
Mature teams also have a good definition of done for their stories This definition leads to potentially deployable software, once the team indicates the story is done For example they might decide that the story has passed all automated unit tests, and all other testing has been performed and passed Then the team shows the product owner who agrees that the story is done The team flags the story as ready to deploy.
Assuming the teams are following processes like these or similar processes, then we have a team with a decent framework for communicating between locations With that framework in mind, let’s examine different repository scenarios for remote teams.
1st Scenario: Two Internal Teams in Different locations and a Remote Third Party Team
Many enterprises use third party off shore teams to complement their development teams The offshore team or teams may be based in India, Brazil, or somewhere that is not the main development offices of your particular organization There are many configurations that this may take. For purposes of this example, our organization will utilize a team in India, and two teams in the US The two teams in the US are based in Phoenix, AZ and Indianapolis, IN.
There are some definite time issues with a team configured like this The team in India has around a 12 hour time difference between the US teams This makes communication, even over a telephone or IM very difficult Unless the teams adjust a typical work day schedule from say a 8am -5pm schedule to a 1 pm – 10 pm schedule, there are very little overlapping hours when the teams are working together.
Also, in the US, there is the issue of Arizona being one of two states that do not observe daylight savings time This means in the summer they are on Pacific standard Time, and in the winter they are on Mountain standard time.
With these disparate teams, how can one team work on some features, check it in, and not clobber changes from another team? There are different takes on the best strategy for agile teams Looking at papers by some Agilists they assume that teams use mature agile practices and those that don’t are capable of using mature agile practices immediately For instance, they assume that teams will work on small bites of functionality as agile is introduced The team will have a story finished, including fully tested within two to three days.
I have seen instances where a slower agile introduction approach works In other words, it takes a lot of time for a team to mature Hence the term “mature”!
In many instances, the teams that are third parties are not mature agile teams Some organizations initiate partnership with third party development organizations without a lot of input from their internal development organizations. While these development organizations lament their exclusion from the process, their management takes the attitude that they have helped the internal teams increase capacity
In that situation, the reality is that the team must work well with a third party team. To help accomplish this make your team’s rules transparent to the third party team This transparency can be communicated verbally, and through pictures Below is a sample of how your team can use a flowchart that teams can keep to remind them of the rules.
Figure 2: Rule Flowchart
The above graphic shows that each time there is a check in, a Continuous Integration build is triggered Each time a build is triggered, the unit tests (automated, small) must pass before the build gets deployed to the CI environment The other understanding documented here, is that someone from the Indianapolis team must perform a Team code Review with the vendor, before merging the code to Main.
This type of team scenario is typical in many enterprises Because of this scenario, each third party remote team needs an isolated branch This isolated branch helps isolate any problems encountered because of the time differences and communication difficulties Do not communicate this as a punishment, but a way to help communication.
Then one of the internal teams can lead the Team code review This team code review gives participants more knowledge of how the team codes correctly. The team continuously learns to improve their process.
2nd Scenario: Using a Distributed Team
The 2nd Scenario involves one team with all team members distributed across North America with one member in South America For an example, this team consists of 4 developers 2 QA types, a BA, a Product Owner and a Lead Developer/Scrum Master.
In this scenario, all team members live in different parts of North and South America Two Developers live in Tampa Florida One lives in San Diego, CA, and another lives in Austin Texas One QA and the BA live in Orlando, FL, the other QA lives in Sao Paulo, Brazil The Product Owner lives in Tampa Florida also.
This team is a virtual team. While those in Tampa could work together in person, they hired on as remote workers When they hired on the company understood they would work from home.
All team members utilize a centralized repository for their code This team needs to be communicating their changes throughout the day as they develop and test Doing this from their remote locations introduces communication difficulty Below are methods that help ensure that these remote teams communicate changes throughout the day to each other.
Figure 3: Communication
There is a source code repository that all members have write access to check in code to Team members must check in regularly, WITHOUT breaking the build They must run all automated tests for this Also, the team members should apply labels, and comments There is a Dev branch that is used for new feature development.
Since this is one team, they use one branch This one feature branch (called Dev in the diagram) isolates new development The benefits of isolation, especially for a team learning mature practices include the ability to isolate out defects introduced with new feature development As QA members use more agile techniques, they want to run end to end tests on the most stable release your team has. This isolation helps provide an easy way to grab more stable code from the repository.
The team uses a main branch for more stable code that deploys using a weekly build for end to end testing The team also needs a release branch that isolates different releases and allows the team to have service releases and hot fix releases with the code in production As the team matures, they can reduce some of these branches The 3rd scenario shows how that team can work.
The team does need to communicate in as many ways as possible when merging code Teams add comments, or label check-ins as shown above. That is the start of communication between the teams, not the end Team members communicate using their IM and of course via the daily standups, demos, retrospectives and planning meetings.
Team Leaders encourage this via many techniques With your source code, teams perform learning code reviews These code reviews cement the teams coding style, help junior members understand why we code the way we do Evaluate any great unit tests and suspect unit tests in the reviews These reviews are done critically, but not by pointing fingers at specific team members This previous article by the author shows how to do a team code review that helps teams learn.
All this activity pushes your team towards a more mature level!
What Should My team Do?
These two scenarios have touched on where most teams are at in their development maturity Evaluate the scenarios and look at the maturity level of teams, locations of teams to help decide Then strive to continuously improve and aim to become a highly mature team!