DiSSCo Prepare Deliverable D3.3 (including MS3.10) - Distributed Teamworking Practices and Pilot

36 Abstract As a highly decentralised research infrastructure, the Distributed System of Scientific Collections (DiSSCo) will need to develop cross-institutional teams, adopting work practices where individual staff are intensively working collectively on common tasks in a distributed environment. Since DiSSCo Prepare Task 3.3 on secondment and distributed working was first envisaged, there has been a step change in distributed working owing to the Covid-19 pandemic and lockdowns or other restrictions to where work could take place. This deliverable examines distributed team working practices and how they have changed, through interviews with a range of key roles across DiSSCo Prepare institutions. It briefly examines key project management and technical team delivery techniques. It documents how some of these approaches have been piloted within DiSSCo Prepare for the development, testing and delivery of DiSSCo Policy and Digital Maturity tools. Finally, bringing this together with previous work on secondment policies and practices for DiSSCo, we make recommendations about how secondment and distributed team working can be approached to enhance DiSSCo capabilities and the likelihood of successful implementation of the research infrastructure. Contribution to DiSSCo RI DiSSCo Prepare1Work Package 3 covers capacity enhancement, supporting the Data Readiness dimension which forms one of the five dimensions within the DiSSCo Prepare Implementation Readiness Levels2, helping to prepare DiSSCo facilities to work towards new institutional roles, and new technical infrastructure requirements, supporting digitisation, exploitation, and enrichment of digital collections. Task 3.3 develops approaches to secondment and distributed team working for DiSSCo, which will be essential to the delivery of the research infrastructure across a highly distributed range of delivery partners and a geographically dispersed set of scarce resources and skills, particularly in more technical roles. Keywords Secondment, distributed working, teamwork, capacity, capability, competency, skills, human resources 2https://www.dissco.eu/dissco-ppp/ 1Distributed System of Scientific Collections - Preparatory Phase Project. Grant agreement ID: 871043 https://doi.org/10.3030/871043 2 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 Index Abstract 2 Keywords 2 Index 3 4 01 INTRODUCTION 4 Distributed working in DiSSCo 4 02 DISTRIBUTED WORKING TOOLS AND PRACTICES 6 Approach - distributed working interviews 6 Where and how work is done 6 Tools - hardware and software for distributed working 8 What’s working well and less well? 9 Recruitment and induction 10 Events and collaboration 11 03 DISTRIBUTED WORKING PILOT 13 Approach to the DiSSCo tools 13 Tools and Platforms 13 Work with SYNTHESYS+ on the metadata schema 14 Tool development and delivery timeline 14 Phase 3: Development Phase: January - July 2022 18 Reflections and lessons learned 19 04 CONCLUSIONS AND RECOMMENDATIONS 21 Distributed team working and secondment in DiSSCo 21 Annex 1: Distributed working interview brief & schedule 23 Background 23 What? 23 Who? 23 How? 23 3 Interview schedule 24 Questions 25 Personal details 25 You and your team - where you work 25 You and your team/institution - working practices and tools 25 What has gone well or less well? What’s next? 26 Events and collaborations 26 Closing 26  4 01 INTRODUCTION Distributed working in DiSSCo 1.1 DiSSCo will be a highly distributed research infrastructure, geographically and institutionally. It will need to ensure effective delivery of technical infrastructure in a way that draws upon scarce resources and skills based in different teams and locations; as well as ensuring joined up and consistent approaches across an even wider range of partners for the delivery of content and services, including digitised collections data. Distributed team working, enabling individuals and groups to work effectively together for delivery, is therefore critical to DiSSCo implementation. 1.2 The experience of working on DiSSCo Prepare and previous related projects has already provided extensive experience about distributed working across the many partners involved in work packages and tasks; including tools for virtual collaboration and central project management, such as use of the Teamwork project management software3. Originally, it was envisaged that this task would focus on best practice from our own and other research communities and wider industry (e.g. broader technology development approaches). 1.3 Since then, however, the outbreak of the Covid-19 pandemic and widespread lockdowns from 2020, and other measures that impacted where work took place, have transformed the landscape of distributed working. Many more teams and individuals now make daily use of tools for virtual collaboration, and have changed their policies and approaches to where and how work takes place. In this context, ‘best practice’ has become more fluid - approaches are still developing and falling into place, with a wide variety between different sectors, organisations and teams. In order to recognise this shift, we decided to adopt a semi-structured interview approach, exploring the topic of distributed working and the changes over the last two years in more detail with a range of key stakeholder and roles, including technical and coordination roles. 1.4 This report presents the insights from those interviews. We then look at how some of these approaches have been applied in the context of developing two tools for DiSSCo, and the lessons from that pilot. 1.5 Previous work in this DiSSCo Prepare Task 3.3 has examined secondment procedures for DiSSCo4, concluding that DiSSCo secondments would need to benefit not only the individuals and institutions directly involved, but also the wider needs of the DiSSCo infrastructure and consortium, delivering either skills growth / transfer considered to be needed for DiSSCo implementation, and/or concrete delivery of DiSSCo components such as technical infrastructure development. For the most part, distributed team working is likely to be a simpler and more cost-effective approach with constrained and distributed resources than full secondments of staff from one institution to another; however these approaches can be complementary, falling along a spectrum of options available to DiSSCo to ensure that the right skills are deployed to the right tasks at the right time. Distributed teams may need some in-person establishment time, for example, or secondments could be virtual and for the duration of a particular task, illustrating the close relationship between these two areas. Chapter 4 of this report sets out our conclusions 4Hardy, H., von Mering, S., Berger, F., Giere, P., Mergen, P., Koivunen, A., Weiland, C., Grieb, J., Vipp, M., Põldmaa, K. (2022) DiSSCo Prepare Milestone 3.9 'Secondment Procedures for DiSSCo' https://doi.org/10.34960/bms6-tf66 3https://www.teamwork.com/about/ 4 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 and recommendations, bringing together our work on distributed working with this previous analysis of secondment procedures, and with the wider work in this Work Package about competencies and skills. 02 DISTRIBUTED WORKING TOOLS AND PRACTICES Approach - distributed working interviews 2.1 Following the changes to working practices resulting from the Covid-19 pandemic, we wanted to seek the views of our community on best practices and on what was working well and less well for them in terms of the tools and approaches available for distributed working. We considered a survey approach, but felt that a smaller set of semi-structured interviews would enable a deeper exploration of the reasons for preferring different approaches, as well as allowing us to explore what changes have taken place and why in particular teams. 2.2 Interviews were carried out over September - November 2022. Interviews were carried out by task partners, largely within their own institutions to facilitate understanding of local organisational structures and practices, and to allow interviews to be held in the first language of the interviewees. A total of fifteen interviews were conducted - a full schedule and the interview questions brief can be found at Annex 1. Interviewees were chosen to represent a range of key roles in relation to DiSSCo infrastructure development and use, including developers; digitisers / digitisation coordination roles; curators & collections staff; researchers; SYNTHESYS Virtual Access coordinators; and roles representing CETAF and the DiSSCo Coordination & Support Office (CSO - the central organising hub of DiSSCo). Some quotes from the interview notes are interspersed with the summary below, to give a flavour of the responses. Insights from the distributed working interviews Where and how work is done 2.3 All interview respondents had previously worked primarily at their institution, but worked for an extended period wholly or mostly at home during the pandemic lockdowns in 2020 and often beyond. 2.4 Both institutional and personal approaches towards coming back to work and the balance between virtual and in-person working vary considerably. For institutions, some have retained a very fluid policy, for example allowing employees to agree with their manager whether and when they may need to be on site. Others have established a minimum percentage of time or number of days to be in the office (ranging from 20-60% for all staff, up to 100% in roles which require a physical presence) - although typically these policies still allow for greater home working than before the pandemic, and even for those on site full time some flexibility in working hours is appreciated. Some roles require in-person working all or most of the time, for example digitisation which requires proximity to collections - although even for these there is somewhat more flexibility than pre-pandemic e.g. transcription activities can sometimes now be conducted remotely. Some teams had had members working partly remotely before the pandemic, often in e.g. technical roles, but this is considerably more prevalent now. Fieldwork paused for many for a long time, but has now mostly re-started similarly to before Covid. 2.5 For individuals, there was also a lot of difference in approach, depending on roles and personal preferences. There is currently a full range of working locations and patterns from 6 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 almost entirely remote to full time in person. Some strongly preferred to return to the office, often because they found it preferable to see colleagues in person and have company and more regular interaction, or felt meetings are better in person. Others preferred the flexibility of remote or mixed approaches, and the absence of distractions and disturbances at home. Those who attend the office perhaps a day or two a week noted that they use their office and home working days for different purposes, e.g. working on documents or code at home, and using in-person time to support their team, maintain personal contacts or attend key meetings. Newer staff in particular appreciate the opportunity to be in the office to meet more colleagues. ‘Working online has the great advantage of being more flexible (less long term planning for in-person meetings etc.) and it results in much less travel. The down-side is that people miss the non-work related aspects of an in-person meeting, e.g. a common dinner’ 2.6 Some key areas of work were affected particularly strongly by lockdowns and remote working, including work in laboratories (e.g. for research analyses and advanced imaging); teaching; and work on collections (including digitisation). This was difficult, but also had benefits in terms of innovation and ingenuity in coming up with new approaches. In particular one interviewee who manages laboratories felt that the pandemic had encouraged agile problem solving that the team had found rewarding. This had included good collaboration and a sense of shared mission with other teams, such as a more flexible approach adapting IT security to enable remote technology access; and had resulted in good options for many users including guided remote access with a small on site staff, although software solutions for remote access were not always successful (e.g., time lags / latency affecting imaging solutions). These changes also involved a change of model, from training users to support themselves, to a more service-based approach - this was not entirely positive and has now largely been reversed, as it is good to build user capabilities through training and self-supported work. ‘...strangely the best thing I think about it was that temporary period where we were just thrown into the task of solving a huge amount of problems as quickly as possible, with freedom to literally try stuff…that side of things worked really, really well and now we're back into the kind of routine grind - it's less enjoyable’ 2.7 Some interviewees commented on how changes to working patterns have affected productivity, and here again there have been mixed experiences. Not commuting, and doing work suitable to home working, perhaps with fewer meetings, were felt to have been good for productivity. And some ‘backlog’ tasks such as completing publications were achieved during lockdowns. But work that requires physical presence, e.g. work on collections, had of course to be paused. 2.8 Many, but not all, interviewees had experience of working in DiSSCo or linked projects as distributed teams across Europe before the pandemic. Distributed working using English as the common language is not considered problematic for most teams, certainly for those directly involved in DiSSCo distributed working currently but often for their wider teams as well. Many teams within institutions are multi-national and multi-lingual in any case, particularly in the Netherlands and in Brussels, and may use English in other working contexts besides DiSSCo, e.g. University of Tartu (Estonia) maintain their development documentation in English. Nonetheless, it is helpful for DiSSCo to retain a focus on language, e.g. to think about language(s) for infrastructure access and training. Some wider teams are less fluent and this may impact wider DiSSCo communications and engagement with potential users. And some respondents mentioned that, for example, they find writing in English harder than speaking or vice versa. ‘Sometimes it would be nice to be able to express yourself in your own language. But I'm used to using English because it's the working language in our team anyway’ Tools - hardware and software for distributed working 2.9 All but one respondent had been issued hardware for remote working by their institution (and the one who had not could have requested this if they wanted it) - usually laptops, peripherals such as headphones, and sometimes mobile phones. Some preferred to use their own hardware when working at home, which was often of a higher standard. ‘...our employer would have provided all hardware except the desk, but I chose to use some of my own or buy some myself so I don’t need to take them back to the office.’ 2.10 Tools for distributed working make a huge difference - the prevalence of these and their high take up and increasing familiarity to many people in lockdown have had a permanent impact on how work is done. While many institutions have particular software supplied for primary work use, it is common to use multiple tools for different projects, contexts or collaborations. Specific comments were made about particular software as follows: ●The most common video conferencing solutions are Zoom and Teams. Some also use Google, Skype, Webex and BigBlueButton (a platform designed for online education). One respondent commented that in BigBlueButton it is easy to set up a common virtual room where all members of the group can always enter and start a conversation. Less familiar apps, or those not supported by institutional IT teams, were generally more likely to cause problems, and most people sometimes experienced problems joining meetings. Overall Zoom is preferred by most. ●The most common chat/messaging apps used are Slack and Teams. Slack was mentioned as having good integrations, and is also used by some now for conferencing. One respondent mentioned an increase in emails with remote working, while for others chat tools such as Team and Slack have displaced email traffic. Matrix Chat was also mentioned by one interviewee. ●Google was preferred by most for collaborating on documents, spreadsheets etc and for the functions of Google sheets (better linking between sheets, good querying language). Microsoft collaboration tools are found to have time lags and other issues. ●GitHub and GitLab are preferred for collaborative work on development projects, technical documentation, and code. ●Most interviewees are familiar with DiSSCo’s use of the Teamwork software for project management, but few use this regularly or find it intuitive (including those also using it in other EC projects). ●Miro was the most-mentioned virtual whiteboard - interviewees who have used these tools have mixed views about their usability, with some finding them very versatile while others struggle to navigate them. ●Institutions offer virtual private networks (VPNs) for accessing certain work software - these are useful but accessing some systems remotely (e.g., the collections management system at NHM London) can sometimes be difficult. ●Other tools mentioned included those for storing and/ or sharing files (DropBox, WeTransfer); task, ticket or project management (Trello, Jira, Teams planner, ClickUp, Pivotal Tracker) - where no solution seems to be wholly satisfactory for users, or strike the right balance between offering sufficient functionality without getting too complex; TimeCamp for time recording/management; and the Confluence wiki for internal knowledge sharing. 8 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 Phase 1: User Stories and Requirements: November 2020 - April 2021 3.9 The initial phase of the task focussed on developing user stories and requirements for the policy tool. All task members were invited to meetings to discuss requirements and contributed user stories, with meetings taking place on Zoom and Google Sheets used to collect user stories. The NHM Business Analyst also interviewed potential users of the policy tool during this phase, which included users from outside of the immediate task team. User stories help to explain what an end user needs from a product, and can be used to inform the requirements of the software tool. Table 1: Timeline of meetings during Phase 1 Meeting Date Meeting Type Summary 16-11-2020 Task 7.3 - Agreed to draft Statement of Purpose - Reviewed skillset required 02-12-2020 Task 7.3 - Task members agreed to provide user stories before next meeting (using google sheets) - Agreed scope of Phase 1: User Stories, functional/non functional requirements, recommendation for technical approach 17-12-2020 Task 7.3 - Reviewed Statement of Purpose - Reviewed initial user stories 11-01-2021 Task 7.3 - Agreed to classify/categorise user stories - Agreed to develop template for requirements - Agreed to develop milestone outline 20-01-2021 DiSSCo All-Hands Discussion with all DiSSCo partners - Agreed that self-assessment framework was right approach - Agreed to include WP5 representative on task - Noted wider DiSSCo needs for self-assessment tool: link to WP3.1, as well as other considerations 10-03-2021 Task 7.3 - Agreed plan to develop functional requirements in form of acceptance criteria - Agreed user interviews required to develop user stories 23-03-2021 Task 7.3 - Agreed initial prioritisation of acceptance criteria/functional requirements 25-03-2021 DiSSCo WP5 - Review of initial requirements with WP5 Knowledgebase representative 06-04-2021 Task 7.3 - Milestone progress update + request for task members to review document - Discussion on developer resourcing and synergy with WP3.1 08-04-2021 DiSSCo WP5 - Review of initial requirements with WP5 Knowledgebase representative 14-04-2021 Task 7.3 - Milestone sign off Updates were also provided as required to wider Work Package 7 or business stream meetings. 3.10 The NHM Business Analyst conducted semi-structured interviews with potential users from NHM, Meise and Luomus (5 interviews). Task members were asked to invite colleagues who would use the policy tool within their institutions to take part in these interviews. These interviews were conducted over Zoom. The distributed nature of the task meant that colleagues from across the consortium could be interviewed, meaning there was a wider variety of experience than if a single institution were involved. These interviews were used to create new user stories, and to test that the user stories already gathered from task partners were mentioned when speaking with ‘real’ users. 3.11 The output from this phase was the Policy Tool Design Blueprint, which included a set of user stories outlining use cases for the policy tool, and the functional and non-functional requirements for the tool. The functional requirements were mapped to the user stories, and were written in the form of acceptance criteria (French et al., 20216). Phase 2: Technical Preparation Phase: May - December 2021 3.12 In the first task meeting following the completion of the policy tool design blueprint, a project plan was drawn up for the rest of the task. This included a technical preparation phase, where the roadmap for development would be agreed, followed by a series of build and testing phases (Fig 1). Figure 1: Initial project plan for the development of the policy tool. 3.13 Task partners also discussed the similarities between the requirements of the Digital Maturity Tool from task 3.1 and the policy tool. A representative from T3.1 attended this planning meeting, and it was agreed that one platform would be developed for both tools, allowing for consistent user 6French, L., Woodburn, M., Blettery, J., Casino, A., Groom, Q., Hyvarinen, M., Loo, T., Paleco, C., Pim Reis, J., Scory, S., Semal, P., Tilley L. and Smith, V.S. 2021. DiSSCo Prepare Milestone report MS7.5 - Design of the DiSSCo policy framework tool.. Pp1-20. https://doi.org/10.34960/0ARZ-6D39 16 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 experience, and enabling work package three to focus on the content of the maturity tool, rather than the technical development (which the work package was not resourced to cover). 3.14 It was also agreed the task would be split into three groups during the technical preparation and development phases to help task members focus on their areas of expertise. ●Developer Group: This group consisted of people with technical expertise, from T7.3 and T3.1, who would either be directly involved in the development of the policy/digital maturity tool or would be able to provide advice on technical aspects of the task; ●Business Group: This group was formed to provide a forum for the Developer Group to consult with business-related questions. Membership included task partners with knowledge of DiSSCo CSO requirements, as well as those with business analysis and project management skills. There was representation from both the digital maturity tool and policy tool tasks. It was intended to give developers a place to get quick feedback on user interface design, and to get agreement over any issues or queries; ●User Testing Group: This group included people who were identified as likely users of the policy and digital maturity tool, and they agreed to be involved in the user testing of the tools. There was some overlap in membership of this group and the business group. 3.15 The Developer Group led on the technical preparation phase. They met to agree on development principles for the task (Fig. 2) , and agreed to adjust the initial timetable (Fig. 1 above) to one which incorporated agile principles (Fig. 3). Rather than having distinct phases of development and testing, instead the task would have an iterative build phase where user testing took place on early versions of the tool to inform the next phase of development. This would allow for more flexibility and better aligned the project with current software development best practices. Figure 2: Development principles for the implementation stage of the Policy and Digital Maturity Tools Figure 3: Updated task timeline, which includes an iterative build phase. 3.16 The Developer Team consulted with the DPP WP5 team to discuss the level of integration with the DiSSCo Knowledgebase. The options ranged from a tightly-coupled integration, where the Knowledgebase would contain the metadata schema and policy tool, to a more loosely coupled approach where the Knowledgebase would host DiSSCo and institutional policy documents but a separate policy tool would be developed. After discussions, this loosely coupled approach was taken. Primarily this avoided complicating the development of the Knowledgebase with additional, new requirements during the final stages of the WP5 team’s work, but also the T7.3 developer group also decided that the potential upsides of developing the forms and interfaces for the tools inside the Knowledgebase would likely be undermined by the complexity actually doing this, and then maintaining these customisations in the future. 3.17 Once these decisions were made, the Developer Team focused on practical questions regarding programming language and framework choices for the development work. After discussions, Python was selected, with the main backend of the web app being developed in the Django7web framework. Using Python aligned with the existing skills within the team as well as making use of one of the more well known and popular languages around today thus ensuring ongoing maintenance would be as easy as possible. The choice of Python also aligned with previous choices the DiSSCo Tech Team have made for other services, where Python and Java have predominantly been used. The frontend of the web app would be developed in VueJS8, again in line with existing team skills, thus ensuring a modern, responsive experience for users of the tools. Phase 3: Development Phase: January - July 2022 3.18 The development team used the available tools, most notably GitHub, to manage the work and work collaboratively in a mostly asynchronous manner. Virtual meetings were mostly organised ad hoc and called when there was a need for a wider discussion about a particular choice (for example, the initial choice of languages/frameworks). Given the fairly short timescales of the development work, it proved challenging to organise the development work of bootstrapping a new project from scratch while working in a distributed environment. This was compounded with communication delays and holiday clashes, for example where different countries have different schedules and traditional holiday patterns. These issues made collaboration harder. 8https://vuejs.org/ 7https://www.djangoproject.com/ 18 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 3.19 The Business Group agreed to meet every 2 weeks for half an hour, which allowed the developers to bring urgent queries to the group for discussion. The Business Analyst and Lead Developer met a few days before the scheduled meetings to set the agenda: if there was nothing to discuss the meeting would be cancelled. The meetings had only one or two items on the agenda, allowing for a short discussion and a decision to be made. 3.20 User testing sessions were arranged over zoom, scheduled for 45 minutes. Users were given a login to the policy tool, asked to share their screen and talk through their thoughts as they used it. The Lead Developer and Business Analyst led these sessions. This helped to develop the policy tool, with feedback incorporated into the next phases of development. Feedback on the design was also sought at task meetings of T3.1 and Synth NA2.1. Reflections and lessons learned 3.21 All DiSSCo development tasks are likely to involve complexity and cross-boundary, distributed working of some kind. It is important not only to involve the DiSSCo Technical Team in software development, but also to have representatives from the business and wider community. A project manager is essential to ensure the work is on track, and also to facilitate conversations between the distributed teams. 3.22 It’s helpful for project teams or groups who have to work together on distributed activities to have flexibility and agency in the selection of their tools and approaches, so that they can choose those that suit the specific people and purpose, and can flex these if there is a need, as the project develops through stages for example. We therefore suggest that DiSSCo provide easily accessible information about tools and best practices, proactively making this available to projects, but don’t prescribe a particular approach. In this case study, the project management timeline was changed to adopt a more agile methodology (Figs. 1,2 and 3 above), and the coding language used by the developers was only determined after discussions on the skillsets of team members. On the other hand, flexibility should be balanced by consistency and suitable re-use of tools, approaches and functionality, with appropriate controls in place to ensure there is consistency across projects where this is necessary, and the DiSSCo Technical Team were therefore involved in these discussions. 3.23 It is important that there is coordination across the different elements of a distributed project. In T7.3, the task team had discussions with the DiSSCo Technical team, the DiSSCo Knowledgebase team, T3.1 partners and the SYNTHESYS+ NA2.1 task. Good communication between these elements meant the project was more successful, for example, integration with the Knowledgebase was considered at a relatively early stage, and the communication with T3.1 meant resources were used more effectively by combining effort. 3.24 In this project, it was beneficial to have a range of institutions involved in the task during the project discovery stage (Phase 1: User Stories and Requirements). The distributed nature of the work meant the task was able to draw on a wide range of experiences to gather user stories, and could benefit from the different networks of each task partner in finding potential users to interview. The availability and improved take-up of video conferencing platforms like Zoom meant users could be interviewed virtually even though they were not directly involved in the project. 3.25 Bootstrapping a development project (i.e., depending only on existing skills and resources rather than e.g., hiring dedicated resources) is harder with a distributed team, and some skills within the team will be drawn upon and required at different stages of the project’s development. This will create natural ebbs and flows in demand for skills and time which must be accounted for and managed. This again makes the need for a project manager essential to ensure the development team’s time is being used best, e.g., limiting the time one individual spends on a problem without the input of other team members. 3.26 The inclusion of technical staff who are likely to do the development work of the project as early as possible is strongly recommended as it ensures continuity in thinking and allows for early feedback to be given around future development choices. The earlier iteration plans can be put into place with development milestones, the earlier developer time (which is likely very in demand at the hosting institution) can be lined up and secured the easier managing the project will be. 20 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 04 CONCLUSIONS AND RECOMMENDATIONS Distributed team working and secondment in DiSSCo 4.1 As a distributed infrastructure, with considerable limits on the availability of resources and of skills including technical skills, it is imperative that DiSSCo make the most effective use of working tools and practices to enable construction and use, drawing on the distributed skills and competencies across the DiSSCo network. 4.2 This could involve secondments - where a member of staff is assigned to another institution for a fixed period. DiSSCo secondments will not only need to meet the needs of the individuals and institutions concerned, e.g. for skills development and knowledge transfer, but will also need to deliver specific tasks for the DiSSCo infrastructure itself. This is a fairly complex balance, that would therefore likely need central incentivisation and coordination to overcome the barriers to organisations freeing up resources. 4.3 Secondment has the benefits of embedding an individual into a specific team and task, avoiding competition from their wider role during the relevant period, and of offering skills development on all sides - however it can be complex to incentivise and arrange. It is likely that many DiSSCo needs can be met more straightforwardly through distributed team working, building on the work already done throughout DiSSCo Prepare. 4.2 There is no ‘one size fits all’ approach to distributed team working or distributed infrastructure development that DiSSCo should adopt. ●Different individuals have different preferences and personal constraints, for example for where they primarily work; ●Different institutions have adopted different practices and policies post-pandemic, for example different requirements about on site working time; ●A very wide range of free and paid-for software tools are available for all aspects of virtual collaboration, from sharing code and documents, to video conferencing, chat and task, time or project management; ●Different approaches to project management and to development have different pros and cons in different circumstances or teams, e.g. may suit the skillsets of existing developers, or may fit well with other relevant DiSSCo tools or platforms; and ●On occasion, distributed team working will also involve commercial suppliers or partners, who may have their own preferred approaches. 4.3 In this context, it is important that tools and practices work for teams, rather than the other way round. DiSSCo should aim wherever possible to allow flexibility for teams to specify the tools and approaches that they prefer. It is important, however, that teams are supported at the outset to discuss and agree their approaches and expectations in a structured way, so that for example work is shared in one agreed location and all team members and stakeholders are clear on where they can find information or how they can collaborate with each other. It is also important that tools and competencies are reused where possible, so for instance teams may be able to choose from a couple of options but not a limitless list - cost of course may also be a consideration here. 4.4 On the project management side, there is extensive information and training widely available that this task has not attempted to duplicate. Again, flexibility to select the best approach for each project in DiSSCo is desirable, within whatever central approach is adopted to managing timelines, dependencies and resources. However, it is likely that in setting up a distributed infrastructure in a constrained timeframe with a complex stakeholder network, Agile approaches that prioritise rapid testing, regular showcasing of emerging products and continuous improvement are likely to be most relevant, as reflected in the pilot above. It is also likely that product management type approaches, that think about the life cycle of DiSSCo products and services and engage multiple skills and stakeholders in this from the outset, will be beneficial.9 4.5 While the challenges of DiSSCo infrastructure and service development are high, DiSSCo will benefit from the experience of many technical and other colleagues in collaborating remotely in distributed teams for DiSSCo Prepare and other projects. The programme is also already benefiting from the explosion in virtual working and the greatly increased familiarity with a wide range of tools during and following the pandemic, making distributed team working a reality for many people across our sector. 9https://en.wikipedia.org/wiki/Software_product_management 22 H2020-INFRADEV-2018-2020 / H2020-INFRADEV-2019-2 Annex 1: Distributed working interview brief & schedule Semi-structured interview brief Background What? Part of the remit of DiSSCo Task 3.3 is to examine best practice for distributed teams to work intensively and collectively on common tasks; and to share expertise where particular skills may not be locally based. The Covid 19 pandemic also saw an explosion in remote and distributed working and events. We are now conducting some interviews to understand within the DiSSCo consortium what changes to working practices and tools have taken place, and what the experience of this has been like for those involved - drawing out best practices and lessons learned to inform Task 3.3 analysis and recommendations. Who? In the first instance, we have asked members of the consortium who are working on Task 3.3 to nominate one or more people in their institution (including themselves if relevant) to be interviewed. We will also invite particular stakeholders such as those working on the ELViS platform. We will seek to balance interviewees to represent insights from different communities including developers/technical; managers/leadership; and those coordinating DiSSCo centrally. How? Rather than providing a survey, Task 3.3 members will conduct interviews, usually virtually, to allow for discussion and follow up questions as well as a consistent format of responses. Interviews are expected to take up to an hour. Interviews will generally be conducted in English - however if you prefer another language we may be able to accommodate this and translate afterwards. Your consent is requested to record the interview with you (if possible); to make notes or transcribe interview content; and to use this in the relevant Task 3.3 Milestone or Deliverable, either summarised as general themes, or from time to time as a direct quotation. Please confirm in writing and/or raise any concerns with your interviewer. Interview schedule Interviewer Interviewee(s) Date (2022) What/who represented Helen Hardy NHM London NHM London: Josh Humphries Peter Wing Alex Ball 20th Sept 27th Oct 25th Oct Developer working on DiSSCo tools Digitiser and SYNTHESYS Virtual Access coordinator Imaging lab manager, supporting remote users Kadri Põldmaa TARTU Uni. of Tartu NHM: Villu Soon Allan Zirk Kadri Põldmaa 3rd of Nov 4th of Nov 15th of Nov Researcher, curator Lead developer Head of collections Jonas Grieb SGN Senckenberg: Hanieh Saeedi Thomas Winter Anke Penzlin 21th Sept 21th Sept 11th Oct Coordinator Developer Data curator Sabine von Mering MfN MfN Berlin: Anja Blessing Peter Giere 10th October 31st October Research coordinator Curator of the Embryological collection Anne Koivunen Luomus Luomus: Anniina Kuusijärvi, Jere Kahanpää 5th October 6th October Systems Analyst Digitisation coordinator (insects, collections) Helen Hardy NHM London ELViS - Naturalis: Sharif Islam 12th October Technical development of ELViS & DiSSCo CSO Helen Hardy NHM London DiSSCo CSO and CETAF: Ana Casino 6th October CETAF and DiSSCo CSO 24