Work Optimization in Distributed Agile Development Projects

13 December 202112 October 2018 | Software

The article gives you an overview of Fortech’s experience with distributed Agile development projects of various sizes. It illustrates the challenges we faced and the effective solutions we found to most of them. The post also captures the significant contribution of the delivery department to making our Agile development process successful.

To give you an idea of how to apply in real life the concepts presented we included a comprehensive case study. This example shows the Agile concepts at work in our development process.

Fortech embraced Agile SCRUM in the early days of this promising development approach. Since then, we have been adding many bricks to the foundation set by Fortech’s early adopters of Agile, reaching a point where our experts have unraveled most of the methodology’s secrets. As providers of Agile development, we mostly work in distributed Agile teams, which pose a variety of challenges. To overcome them we tackled the problems from many angles. One of them, work optimization in distributed Agile development teams through operational excellence, is the main topic of this post.

The Building Blocks

Fortech has been involved in a diversity of projects developed across multiple continents. Most of our customers are from Western Europe and North America. For some of them, we joined forces with teams located in Europe and India. We thus became acquainted to cooperation across significantly different time zones. Working Agile with our customers’ co-located teams, we learned how to overcome hurdles and become efficient in a distributed team.

We uncovered the secrets of the standardized approaches of Scrum of Scrums and large-scale Scrum. In addition, we learned how to make the rigid corporate planning work hand in hand with the Agile loose planning. Combining these two worlds leads to the flexibility and lean approach required by the dynamic businesses of our customers. We also learned that scaling Agile requires prompt feedback among teams, which permits the timely implementation of changes.

The Main Challenges of Distributed Agile Development Projects

Ensuring quality communication and close ties between team members has been our biggest challenge with large distributed Agile development projects. To cope with this situation Fortech relies on strong leaders, with excellent communication skills and great work ethic. These leaders must keep their promises and make sure that co-located team members meet face to face frequently. Such meetings are useful even if conducted via webcam.

Derived from the first challenge are the obstacles raised by time zone differences. We partly addressed them by having project leaders with strong communication skills. Time zone differences can also be turned into benefits for both the client and us. They can bring business continuity, 24-hour operational support, and modular code development. In addition, splitting the work among the teams can make code development more efficient.

Another important challenge with teams distributed across different countries is to respect the cultural norms of the other team members. Key for building trust and collaboration across Agile teams, these norms are often hard to grasp and adjust to.

Guided by Geert Hofstede’s principles, we have been learning how to overcome all these challenges. Fortech is now successful at building long-term business collaborations with clients from a variety of cultures and nations.

The next paragraphs present operational measures we have been taking to address the challenges mentioned before.

Key Measures to Streamline Distributed Agile Development

We have been adapting continuously to increase our effectiveness and efficiency in distributed Agile teams. In doing so, we kept adding into our processes best practices to ensure team efficiency, employee and customer satisfaction. We grouped these practices in five categories. The ones in the first category help building a strong team, while those in the second ensure efficient activity planning. The measures from the third allow building independent, cross-functional teams while the fourth address cultural aspects. The last category includes measures meant to ensure continuous integration.

1. Team Bonding

Setting up the distributed team is the first step in an Agile development project. Once this is done, we recommend to our client to schedule a training session at a single location. Key here is to make sure as many team members as possible attend it. As we are not the product owners in most cases, the client has full control over the operational measures.

Bringing the entire team together speeds up the initial bonding. As good relationships among team members are critical in any distributed Agile development project, this training makes a real difference. We then propose to keep parallel events of the team members set at all the teams’ locations. The teams can then share their experiences virtually. This builds trust within the project team and increases team cohesiveness. To strengthen this bond, we schedule team-building events periodically, create a virtual community and support ongoing collaboration within that community.

Some of the measures we rely upon to this end include:

• Setting up high network bandwidth for video-conferencing;
• Making discussion recording and sharing easy;
• Setting up Skype for Business for instant messaging and video-conferencing and accepting any tools proposed by our clients;
• Maintaining a project knowledge hub on Confluence and giving appropriate permissions to all the team members;
• Providing our Project Managers with access to Agile project management tools like Microsoft Project and Jira.

2. Careful Planning

Careful planning is the second key pre-requisite to success with distributed Agile development projects. We do task planning and pre-planning during the weekly or even by-weekly backlog review sessions. In addition, we try to map several sprints in advance. In these meetings we discuss and, if necessary, adjust the backlog.

To make sure every meaningful idea is shared and considered, we encourage all the team members to participate actively in daily sprint meetings and core meetings. All these measures increase self-reliance in team members, as well as their willingness to contribute to the meetings.

When planning a project, we account for the difficulty some team members may have focusing in meetings. This situation occurs mainly with considerable time zone differences.

We address it by:

• avoiding sprint sessions at the end and beginning of the week when the time zone difference exceeds 8 hours;
• keeping the public holidays for each location of the distributed team in a place where they are hard to miss. This place may be the bulletin board or a separate page on the project’s Confluence space;
• defining core hours for all members of the team so that they overlap working hours in all the time zones of the distributed team. During these hours all team members commit to being available for meetings;
• scheduling all the meetings of the core Agile team during the core hours.

3. Building Independent, Cross-Functional Sub-Teams

We find very useful in a distributed Agile development project to have the main team formed of independent, cross-functional sub-teams. This means we do our best to avoid location-based roles (e.g. having all UX/UI resources in one location). Each sub-team can work efficiently as a stand-alone team with clear and comprehensive input from the product owner and alignment sessions with the other stand-alone sub-teams. These sessions bring the sub-teams and team members on the same page on technical and functional issues.

Our typical independent Agile team includes a Scrum Master, UI designers, software developers, and software testers. We start with a core team of 2 or 3 people and then ramp it up gradually. The initial core team interacts frequently with the client in the first weeks of the project.

A significant part of this interaction is face to face and leads to a quick transfer of knowledge. By knowledge we mean information about the project, processes, the people in other sub-teams and cultural norms. We then add other members to the team, trying to keep its structure balanced. In addition, we try to include all the roles required to give the Fortech team independence from other project sub-teams.

4. Addressing Cultural Gaps

It is crucial in distributed Agile development projects to quickly address any cultural gaps that exist among sub-teams. The Fortech company culture emphasizes respect, trust, openness, diversity, reliability, and continuous self-improvement. By selecting people who believe in these values, Fortech makes cultural gaps relatively easy to fill. We value all people, regardless of culture or religious belief.

Most of our experienced engineers have been repeatedly exposed to diverse cultures and can quickly adjust to new behavioral patterns. Romanian engineers are straightforward and can easily challenge authority when the situation demands it. To help novices adjust to such differences, we recommend them to do thorough research on how to interact with people from sub-teams located in other parts of the world.

To adjust to teams from other cultures smooth, we always seek advice from people at Fortech familiar with those cultures. We then collect as much relevant information as possible from other sources and start practicing what we have learned. Without always being plain sailing, this approach has produced good results most of the times.

5. Ensuring Continuous Integration and Configuration Management

In addition to the previously mentioned measures, we put considerable effort in continuous integration and configuration management. To do this we:

• have all the developers rely on a single code repository;
• recommend hourly, automated, continuous builds;
• check in as frequently as possible to the same code base;
• provide all the developers with a source repository tool like GitHub for efficient change management.

If you want to learn more about our results in these areas, please consult the following examples:

• Xamarin Continuous Integration with Unit Tests & Acceptance (UI) Tests
• Demo iOS application built to highlight MVP (Model View Presenter) and Clean Architecture concepts

Case Study: Creating an Enterprise Platform. Scrum of Scrums (S.O.S!).

This is a case study representative for an S.O.S. implementation for a very large team. Up to 118 professionals have been working concurrently on creating an enterprise platform.

From independent applications, with 6 Agile teams

It all started with us working in 6 Agile teams on 3 different applications that were sharing emerging business cases. The applications were siblings in behavior, with variations in the flows, but with different codebase for different customers. They had custom implementations and configurations of features for each customer. The mid-size Agile teams worked independently on separately built components of these applications, which were not interacting very much.

Our client sold the products separately, decoupled and with personalized configurations based on their customers’ needs. Of the main differences among the products, we mention their separate road maps, development cycles, and market demand. Having ownership only on one application or component at a given time, one team could be overwhelmed with custom implementations. At other times, other teams would be overloaded; hence, the time to market was long.

New investors proposed a better approach. They wanted to refactor existing applications into one code base with features to be turned on and off. This solution would transform the product into an easy to sell Enterprise Platform. It would also facilitate a quick implementation and customization, as well as a faster time to market. All in all, this was expected to become a unique powerful product with features and data unified from all the 3 applications.

We committed to doing it all in 1 year, with minimum impact on the existing customers. At the same time, we added upgraded technical components, the look and feel and functionalities.

To one platform, 12 agile teams

The Key Initial Steps

We isolated the architects to design the approach and standards together with the project and product managers. The aim was to decide the strategy to merge the applications and to create a sustainable guide for technical consistency and way of working.

In the meantime, the team managers aligned 40 new engineers to start in this setup. This was done in 3 months, including campaigns, alignment of technical recruiters, skills matrix and decisions.

Scrum of Scrums (S.O.S.)

We split the existing 6 teams, which already had a consistent Scrum approach and technique. We created 6 more teams with balanced seniority and transferred previously acquired practices and skills to the new teams.

To make the integration of new team members easy, we assigned to each of them a Technical Buddy. The Buddies took very seriously their role to integrate the new team members into the team and working process.

All the teams included a Scrum Master (SM) and most of them had a technical leadership role coordinate the members. These were cross-skilled teams that established community practices to align their way of working, deliverables and releases. There were separate practices for software development, software testing, business architecture, and Scrum Masters.

To facilitate operations and communication, the teams had individual standup meetings. After each of them, the SM transferred knowledge between the team and the attendants of the S.O.S. meeting. In the S.O.S. meeting, a Project Manager coordinated dependencies and gave direction.

Release Burndown

Releases to a staging environment happened at every sprint end and were synchronized across 12 Scrum teams. A lot of dependencies were mitigated while setting up a new Continuous Integration system. To make sure we were not losing functionality we relied a lot on Automation tests. In addition, we reverse engineered the legacy code and re-used as much as possible.

The results began to show after about 10 three-week calibration Sprints. In addition, the existing functionality started to emerge in the new platform.

Results

One year into this huge effort, our client’s product was stable and could receive new functionalities. In addition, our engineers had the experience of working with many people and dependencies. We created and refined the working process and learned to be efficient.

Once the refactoring was finished, we began deallocating people and moving them to other projects. A ramp-down was possible, with people being absorbed by the initial 6 teams working now on one platform.

We hope this article provided you with a comprehensive view of working in distributed Agile development projects. By reading the examples and proposed solutions, you should be able to overcome the typical challenges of such projects. We hope you can also find an answer to the popular question “Why outsource your dedicated software development team in other countries” and it now seems like a logical and natural option.
About Fortech

Our approach to software engineering combines strong technology and process know-how, Agile delivery methods, and a blend of code quality practices and metrics refined in almost two decades. Since 2003, over two hundred clients chose Fortech as their tech partner. Our dedicated software development teams (.NET offshore development teams, Java outsourcing teams, Mobile development teams, etc.) make our company a reliable, long-term partner.

About the Authors 

Oana

Accomplished software engineer, with extensive experience leading large distributed teams. Currently a Business Development Manager at Fortech, Oana develops strategies for business growth focused on customer satisfaction, service quality, and product innovation and implements the ensuing plans.

Augustin

Senior software engineer experienced in project management, account management, and business development. His professional experience as lead of successful IT projects spans over 10 years and various industries across Europe and North America.

Tudor

Specialist in marketing and sales, with more than 15 years of experience in Romanian software houses. He has coordinated the reshaping of the online presence and sales and marketing processes for all these companies.

Share this article