When teams are working well and firing on all cylinders, you don’t want to mess with them. But what happens when two such teams are merged for the duration of a project? In this experiment we did just that, and what we stumbled upon was a bit surprising – and inspiring!
1. INTRODUCTION
The Agile Manifesto and the 12 Principles behind them provide a philosophical blueprint for delivering quality products while meeting customer expectations. They also support a healthy culture for developers, engineers, testers, and any individuals involved in building those products. What is often taken for granted is the integral role that team plays in implementing these philosophies. While Merriam-Webster defines a team as “a number of persons associated together in work or activity”, BusinessDictionary gives a more functional definition:
Team: A group of people with a full set of complementary skills required to complete a task, job, or project. Team members (1) operate with a high degree of interdependence, (2) share authority and responsibility for self-management, (3) are accountable for the collective performance, and (4) work toward a common goal and shared rewards(s). A team becomes more than just a collection of people when a strong sense of mutual commitment creates synergy, thus generating performance greater than the sum of the performance of its individual members.
Clearly, for teams to achieve the synergy and collective performance described above, a culture of trust, respect, and collaboration must be forged. Such culture takes time and care to develop, must be continuously nurtured, and can be quickly eroded when the wrong personalities or business practices are introduced. Thus, when our organization decided to merge two productive teams into one for an entire project – we knew there would be risk involved.
2. Background
Our company, Fugro, touts itself as “the world’s leading, independent provider of geo-intelligence and asset integrity solutions for large constructions, infrastructure, and natural resource projects” (Fugro at a glance). With 8000 employees located in sixty countries, the company has over 300 staff dedicated to innovation in surveying, mapping, and geotechnics. These “innovation engineers” are concentrated in a dozen offices around the world and in teams of usually 3-8 people. Teams are formed around specific product or service lines within the business, and team assignments are typically long-term, due in part to the steep learning curves associated with the products developed.
Like most inventions, this experiment was born of necessity. We were approached by a client to provide very detailed mapping of a significant area of seafloor in over 4,000 meters of water, and with an aggressive deadline. A computer-vision-based program to improve the accuracy and efficiency of autonomous underwater vehicle (AUV) operations would need to be developed in-house. The project presented a unique opportunity for our company to showcase its culture of innovation and client-driven focus. As such, many eyes were on the project from the very beginning.
Early conceptual diagrams of the project determined the following functionalities – and hence, skill sets – would be required:
- Geospatial data manipulation (data handling, carving into tiles)
- Image filtering, matching, and alignment
- Mathematical modeling and smoothing
- User Q/C of spatial and temporal data points with image overlays
- GIS extensions to support the workflow
Our leadership put their heads together and decided that two teams would be needed to meet the release target. They were selected because of their specific skill sets – the combination of both would be required. The first team, “Team Geo”, consisted of six experienced programmers with backgrounds in electrical engineering, petroleum engineering, computer science, and geography. Skill sets and experience were mostly around GIS, mapping, systems integration, systems monitoring, and data logging. “Team FÊTE” was comprised of three computer scientists with backgrounds in mathematics, computer engineering, physics, and machine learning. That team’s combined experience included point cloud feature detection and modeling using deep learning, engineering and mapping applications development, as well as systems integration. The two teams were already co-located, except for one member working remotely from across the USA.
While assigning multiple teams to a single product is nothing new for Fugro, the teams usually have specific sub-projects or tasks assigned and continue operating independently. The idea of merging two into one is new – and hence was labeled an “experiment”. The remainder of this report details how the experiment unfolded and what we learned from the experience.
3. Joining Forces
The timing of our teams’ transitions from separate projects one was opportune. Both teams were wrapping up previous work while project planners (stakeholders, management, and product owner) were able to work out conceptually what they desired from first release of the new project. A user workflow was drawn up on the whiteboard and deliberated, and datasets were gathered for experimentation and test cases.
Both teams were already running Scrum with two-week sprints, and both teams had similar philosophies about roles and responsibilities on development projects:
- Everyone on the team is empowered and responsible for the success of the projects
- Everyone helps with coding
- Everyone participates in planning
- Everyone helps with testing
Each team had a “lead”, or Scrum master, and neither team had a permanent, dedicated product owner (PO) for their projects. Instead, product owners were typically selected from among knowledgeable staff, often from the commercial side of the business – outside of development. For other projects someone from development would step up to fill that role.
3.1 Roles
Some key development roles needed to be worked out before the project began. The team leads (our Scrum Masters) had to decide early on who was to take charge of the project. Due to the domain experience of one lead, the other agreed to take a “back seat” and assist when needed, at the same time focusing on residual tasks and support from previous projects. For the merged team, having one clear lead helped to avoid collisions of role and maintained transparency for the rest of the developers.
For this project, the business was not able to supply a product owner for the duration of the development. Instead, key users were identified who would step in for 2-3 week intervals to provide input on user stories and assist with testing. Hence, due to the domain experience of the merged-team lead, he also acted as PO.
Each team also had a senior developer / architect. The two agreed to work closely together during the new project to design and review all components and stories. As will be described below, this relationship fostered unexpected benefits for both individuals and for both teams.
External to the teams, our organization has a group of global architects who review designs and code prior to merging into a common master branch. For this project we were assigned an architect located on a different continent from the teams. This created a dynamic where the two teams were working together not only to complete stories, but also toward getting the code approved by the third-party.
3.2 Process
When the project began, the deadline for first release was about 10 weeks out. This was considered very aggressive, and a shorter duration than most projects. Hence, we agreed to run one-week sprints (instead of two) for this release. This obviously meant more meetings, but the shorter cycle would allow us to adapt quickly to technical challenges and changing priorities.
Stand-up meetings were set for 9:00 a.m. each day. Sprint planning would take place on Wednesdays at 9:00, instead of a stand-up. Demos were usually conducted at various times based on stakeholder availability. Sometimes they would happen at 9:00 on Wednesday before rolling straight into the next sprint’s planning.
One could imagine that story estimation and planning might start out awkwardly due to the merging of previously segregated teams. In fact, story point “definitions” were surprisingly similar for the two teams. Team Geo with six people had been tracking an average velocity of 15 points for two-week sprints; while Team FÊTE was averaging 7 points with three people over the same interval. There were some differences to work out, however, such as the use of “sub-tasks” as facilitated by our issue tracking tool. (One team did not usually plan out sub-tasks; instead breaking down stories each day during stand-up, and creating sub-tasks on the fly or documenting via issue comments. The other team used sub-tasks extensively to organize the work of a story). However, all of this was quickly overcome during discussion, followed by consensus, at the first planning meetings.
This is not to say that story planning was trivial. One senior developer comments that “planning was quite difficult in the early phases of the project due to the novel nature of the problem and the relatively large scope. Estimation was tricky at times. Once a framework was established, planning became easier due to focused sprints.”
3.3 Knowledge Sharing
In order to leverage both the domain knowledge of one team and the scientific knowledge of the other, we agreed to use paired programming as often as we could. This provided great exposure to unfamiliar constructs and opportunities for learning while on the job. Story assignments were intentionally selected to maximize chances of success and opportunities for cross-pollination. At the same time, code reviews were often assigned to individuals less familiar with the technical function of the code being reviewed – which gave them chances to become acquainted with functionality while assuring the code could be clearly understood.
As will be shown below, the opportunities for knowledge sharing and personal growth were highly valued by all team members. While not the original reason for conducting the merge, the enthusiasm and morale gained from this on-the-job learning proved to be the single most-cited reason for continuing the practice of temporary merges.
4. Outcomes
In our industry, clients often push back deadlines due to logistical and equipment challenges. This project was no exception. Although we started out with a 10-week release deadline; in the end we had five months, which gave us the time we needed to improve accuracy, create better interactive tools, and ultimately inject more value into our product.
From almost any viewpoint, the experiment was a success. A very technically challenging and hurried minimum viable product was delivered and proved itself to provide the desired efficiencies and accuracy improvements for AUV operations. Stakeholders were exuberant about the product results.
While the two teams had a cumulative velocity of 22 story points per two-week sprint before the merge – that’s 11 points per week – the combined team started out with a velocity of 9 story points per one-week sprint in the technically challenging first half of the project. This was due in part to the steep learning curves and knowledge sharing required in the beginning of the project; but mostly attributable to the required research and experimentation necessary in the first phase – tasks which can be very difficult to accurately estimate. In the second phase the merged team velocity averaged 13 points per one-week sprint. The combined team was working well with all cylinders firing, and stories and tasks were more concretely defined by this stage of the project.
The positive outcomes go far beyond the code produced and functionality delivered. To the team members, the greatest outcome was the experience of shared knowledge, learning, and collaboration. In our first retrospective after completing a sprint, the most-often stated reflection was about the positive energy from the new experience. This energy was centered not only on the opportunity to learn new skills and overcome steep learning curves, but also around the new potential of the combined, more diverse team to be successful.
Eight weeks into the project, the newness had worn off some, but the members were still very positive about the experience of working together. Participants reflected that communication between team members was “excellent”, better than before the experiment.
4.1 Interviews
Near the end of the project, team members were individually interviewed to gain a deeper insight into the value of the experiment. Unanimously, all interviewees responded that they would recommend a temporary merge again if an appropriate project was starting. Also unanimously, team members agreed there were no unforeseen issues arising from the merging of the two teams, and that company management gave adequate support for this experiment.
When asked if each member shared the common sentiment that merging the teams was a positive experience with regard to knowledge sharing, learning, and having the expertise needed to solve the problem at-hand, the following responses were given:
- Rick: I do agree. I’m generally shy, not wanting to bother people. Developers can be less outgoing, personality-wise. It is difficult to bother people you don’t know well – or if you don’t know their skills or expertise. With the merged team, you know who to ask. You don’t mind bothering.
- Marc: Yes, because it was a very technical project, and all necessary components were understood by at least one person on the combined team. Less research was required, so it was faster to deliver the product.
- Anthony: There is a need for developers to continually learn and I think bringing teams together is one way to help promote this. Another benefit is overall team building. Working in teams can result in a “we and them” mentality where communication is strong within a team but perhaps not so much across teams. Merging teams helps break down these barriers.
- Chase: Yes, I do. I personally had a clear benefit from the opportunity of working with other people more on this development.
- Ryan: I strongly agree with this sentiment. The problem we faced was multifaceted and we were able to carve it up and attack in parallel; leveraging strengths of individual team members. By designating key stakeholders in each of these paths, we were able to focus the work effort and avoid conflict. Team members often deferred to the feature expert as to what would be the best path forward. As the project developed, knowledge gained during daily conversations helped to “catch up” the rest of the group with feature experts.
- Carl: From a manager’s standpoint – a strong yes. The two teams walked away with a bond that will hold beyond the project where they are more likely to seek each other’s advice even on project they are not working on together. Further, neither team had all the knowledge to move this technology forward on their own.
From the beginning of the experiment, it was anticipated that merging two teams has potential to create conflict. The question was asked: Did conflict occur, was it anticipated, how was it managed? Most agreed there were no conflicts due to the utmost professionalism demonstrated by both teams. Some elaborated:
- Eric: From the daily development perspective I did not note any conflict. I think all were able recognize who was the best to follow for any of the given parts of development. We each had key roles and everyone accepted that. From the planning perspective it was difficult at times to reach a decision with a large group, so smaller groups would meet to define some of the task requirements and then those were shared with the team.
- Anthony: I don’t think this was the case here. I think our two teams worked really well together and integrated quite easily and seamlessly with one another. Again, I think it had to do with the quality of the team members. There were no inflated egos, and I think everyone respected one another.
- Ryan: The main sources of conflict were small but were oriented around daily work practices like code style, sharing, etc. Our adaptation of internal libraries and practices provided a common path forward but did require more accommodation from the team that was new to these workflows.
- Chase: Not really a conflict, but our team had to adapt more to the other team’s way of working, i.e. the file-folder structure including the sprint folders. This was anticipated to an extent, and we were shown how to work in that setting.
A thought-provoking question arises when considering the impact of differing skill sets and background experiences for merging teams. When asked “Do you believe merging two teams would have a positive outcome if both teams had the same skill sets and background?“, the responses were more guarded:
- Ryan: I believe that team merging could be quite tricky in this scenario, especially if timelines are tight. Teams take some time to build trust and learn how to work together. These things can be accelerated if the teams naturally complement each other, meaning individuals naturally defer to subject experts to provide the best path forward. If not, I believe that conflict would be more likely in the early stages where many high-stakes project-wide decisions are being made.
- Chase: Yes, but less so. Even people with the same skill sets tend to approach problems differently, especially in the beginning stages of thinking. It always helps to be exposed to that in my opinion.
- Rick: Given a choice between same background or different backgrounds, I would choose different backgrounds, in order to increase opportunity to gain new perspectives.
- Eric: Yes, because it would allow the development project to be more efficient, successful.
- Anthony: Yes, I do believe that there would be value. Perhaps not as much value as when the teams bring different skill sets and experience to the table; but I do believe there would be a positive outcome since no two teams work the same. There is potential to learn from how another team approaches and solves problems both on an individual and team level.
Another twist on the merge team experiment was the question of whether to merge temporarily – as was done in this example – or to reassign teams regularly when new projects arise. An alternative to merging teams would be to reassign staff between teams project by project? Would you prefer this approach to a temporary merge, or not? Again, the responses were mixed:
- Chase: No, I do not think I would. I like the idea of the team being specialized. However, I could see some cases where it would be beneficial to loan one or two team members to another team for a very small part of a project.
- Eric: I think the fixed teams are a good way to allow Fugro to get the most out of developers and for developers to gain specific domain knowledge. I also see a temporary merge as a way to break monotony, allowing developers to do something a little different. So, my preference would be to have temporary merge of development teams and then return to your normal team.
- Rick: Teams formed around projects would be desired. This would provide more opportunities for cross-training and growing your knowledge base. It would be uncomfortable at first, but would “round you out” more, and provide opportunity to get to know others in the company. I believe the pros would outweigh the cons. International travel opportunities would be great as well. This could help with support distractions as well – which are a real problem. It’s very difficult to go back and forth between development of a new product and support of an existing one. If project-teams are formed, then perhaps a support and testing team could form at the same time.
- Marc: This depends on the project. There would be potential for large ramp-up when members are assigned to new teams, which could prolong the time it takes to deliver. On the other hand, this problem could eventually go away in the long run.
- Ryan: This is an interesting idea. It would take some flexibility, but would be a neat way to supplement teams as needed. Also, this concept would be expedited by our company’s widely accepted workflow standards (e.g. coding guidelines, lifecycle tools, etc.).
- Anthony: For me personally, I would not prefer this approach. You get used to how your team operates, and this allows you to just concentrate on your work. Going from team to team would require you to learn and get used to a new team dynamic for every project which I think would take away from your work.
Finally, the teams were asked if merging teams in two different locations could work, and what would need to be changed to facilitate the merge? Our company is global and we do have experience working with other development teams and users around the world. At the same time, we must remember the Agile principle that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation” (12 Principles Behind the Agile Manifesto). Most respondents agreed that it could work, but would be more difficult with geographically separated teams. Also, it was agreed that to make it work, the teams would need overlapping working hours. An important consideration mentioned by more than one person is that the initial “growing together” stages could be more difficult in a geographically separated scenario. “It might be necessary to co-locate during project kickoff, or mandate a certain amount of ‘face time’ via video chat in order to build rapport.” Another respondent thought it would work if “each location would champion different parts of the development project such that each could grow their part without impacting the other.” In essence, this would not be a merged team, but componentized teams.
5. What We Learned
Middle and corporate management are thrilled about the lessons learned from the experiment. It is now being shared with the rest of the global organization as a model for future cross-pollination, learning, awareness, and supporting employee morale. This experience affirmed that bringing two teams together for the duration of a project can be very effective for meeting an aggressive deadline, particularly for a project with multiple facets of prerequisite skills and experience. Steep learning curves can be quickly overcome by working with knowledgeable peers.
Quite by chance, we learned that merging teams temporarily can be a refreshing experience for the teams, resulting in high engagement and creativity. It is an opportunity to break away from the mundane and improve communication between teams and individuals. On the other hand, while people enjoy learning from colleagues, some can be shy about mentoring others. We found that by encouraging paired programming and mentoring consistently throughout the project, this timidity can be easily overcome.
We also confirmed what we already believed about our own development staff – that they thrive on challenges, enjoy delivering value to the business, are professional and respectful toward colleagues, and love to learn.
In summary, we believe through this experience we have discovered a winning recipe for merging teams in order to help a challenging project successful. While this is likely not the only recipe, these ingredients proved rewarding for us:
- Development project with new challenges to solve
- Teams with complementary skill sets valuable to the project
- Teams with similar Agile work practices and toolsets
- Co-located teams
- Professional, respectful attitudes of team members
- Predisposed culture of innovation
6. Recommendations
If you have most of the ingredients above and are interested in combining two teams for a project, consider the following recommendations:
- Get to know each other’s talents and passions quickly, and refer to those talents throughout the project when assigning tasks. This could be accomplished by kicking off the project with a meet-your-neighbor retrospective such as “Strengths, Weaknesses, Opportunities, Threats” or “The Roles We Play”.
- Allow extra time in the first planning meetings for working out differences in team practices. Be ready to compromise on story point metrics and definitions of constructs; and then move on. When the teams are already performing similar Agile practices, the combined process is easier for all.
- “Role collisions” (clashes due to team members’ perceptions that their individual responsibilities are made redundant) are a possibility. Having the right personalities and/or good coaching is key, along with careful consideration when assigning tasks. At the same time, leverage opportunities to free-up individuals who often have the heaviest burdens. Usually they’ll be very thankful!
- Encourage paired programming and/or mentoring consistently throughout the project. Or, ensure all appropriate tasks have an assigned pairing group before leaving the daily stand-up. Choose the pairing assignments thoughtfully – so that one person is always in a position to learn from another.
- Schedule regular retrospectives to uncover any hidden obstacles and highlight newly discovered work patterns. Retrospective formats could be chosen by different team members each time.
Finally, I’d like to end with advice from one of my favorite Agile evangelists, Richard Sheridan: “Run the experiment!” If you have a project and a requirement for two teams to work closely together, how much do you really have to lose? The rewards could be significant; and you may discover something new and exciting about your teams or you own organization’s potential.
7. Acknowledgements
I would like to thank the members of Team Geo and Team FÊTE for supporting this experience report with their willingness to share personal reflections and for participating in the interviews. My gratitude is also due to my management for supporting this report and presentation at Agile 2018. Finally, I also thank the reviewers Carl Sonnier and Lise Hvatum, my shepherd, for their time and thoughtfulness in helping to shape up and round out this paper.
REFERENCES
“12 Principles Behind the Agile Manifesto.” Agile Alliance, www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto .
“Fugro at a Glance.” Fugro, www.fugro.com/about-fugro/group-overview/fugro-at-a-glance .
Sheridan, Richard. Joy, Inc.: How We Built a Workplace People Love. Portfolio / Penguin, 2013.
“SWOT – Strengths, Weaknesses, Opportunities, Threats.” Fun Retrospectives, www.funretrospectives.com/swot-strengths-weaknesses-opportunities-threats .
“Team.” Merriam-Webster, Merriam-Webster, www.merriam-webster.com/dictionary/team .
“The Roles We Play.” Fun Retrospectives, www.funretrospectives.com/the-roles-we-play .
“What Is a Team?” BusinessDictionary.com, www.businessdictionary.com/definition/team.html .
