Vital Parameter Monitoring Alternatives during a Crisis — A Feasibility Analysis in the Context of COVID-19

Written by Daniel Senff, Dennis Schmidt, Juan Dominguez-Moran, Severin Haemmerl & Walter Laurito — March 22, 2020

TL;DR

Italy, Spain, and other countries are already experiencing shortage of ventilators.

In Germany the crisis is getting worse by the day. Our doctors are already expressing their concerns about the lack of necessary equipment, including vital parameter monitors

Availability of vital parameters such as (peripheral) oxygen saturation (SpO2), heart rate, blood pressure is key in order to judge health status of patients and to keep an overview of all patients in a given ward

Medical doctors who are currently treating hundreds of Covid-19 patients in Northern Italy and Spain (including measures such as a strict triage to provide treatment only to patients with highest changes of improved/positive outcome and converting ORs into ICUs) assess their situation as follows:

Non-ICU setting: measuring vital parameters 3–5 times per day is sufficient in order to determine worsening health situation of patients; currently enough equipment; skeptical to use non-approved technology (e.g. vital parameters via mobile phone), only for stable patients in worst case scenario
ICU setting: continuous monitoring of vital parameters necessary; currently enough monitoring equipment, but shortage of ventilators; skepticism to use non-approved technology (e.g. vital parameters via mobile phone), only for patients with non-invasive ventilation in worst case scenario
Improvised ICU setting: see ICU setting, but: lack of compatibility / connectivity of monitoring equipment with / to central screens, nurses need to keep overview of all patient monitors
Generally: if the situation worsens, the major bottlenecks will be: sufficient numbers of ventilators, of ICU beds, and of trained ICU nurses

Abstract

We evaluated if smartphones can be employed in ICU and non-ICU environments to improve the working conditions of health care workers considerably during a crisis such as COVID-19.

Based on five qualitative interviews with medical personnel from Italy, Spain, and Germany we found that smartphones can be used most effectively for the visualization of vital parameters in temporary improvised ICUs in minor overstressed hospitals due to a prevalent lack of centralized monitoring and relatively low staff stress levels. In this case the data provided for the visualization is provided by professional measurement devices.

However, the interviewees made clear that lack of qualified personnel, equipment such as ventilators, and effective public health policies to stem epidemiological spread are the major threats to their working conditions.

Motivation

This article is the result of a two day remote “#WirVsVirus” Hackathon session organized in Germany March 21–22. The original project was about developing a solution of collecting and displaying vital parameters with an App/Smartphone-based solution as a make-shift replacement to a bedside Patient Monitor.

Having seen the pictures of overrun hospitals and exhausted medical staff communicated in European media, the authors felt it necessary to review the assumptions of the original premise. To do that, interviews were performed to learn about how hospitals are organized, what processes around patient’s vital parameter monitoring are in place and how these processes changed in crisis regions.
Hackathons are especially primed for building technical solutions, these can be prototypical or experimental. In our analysis we wanted to provide foundational work for other projects that are pursuing innovative technical solutions in the hope that these projects gain a good understanding of the environment their solutions will have to work in and the challenges that need to be overcome.

Methodology

On March 21 and 22, 2020, five interviews with medical doctors from Northern Italy (3), Germany (1) and Spain (1) were conducted. The interview questions are attached. The interviews were partially conducted in a structured manner, however, not every interviewee answered all questions (least answers about mock-up).

The following gives an overview of the five interviewed medical doctors and their respective situation and experience:

MD from an ICU in Berlin, not yet affected by Covid-19 crisis, knows of a Covid-19 patient at his hospital
Anesthetist from an ICU in Madrid, currently treating numerous Covid-19 patients
Gastroenterologist from a regular ward in Milano (Northern Italy), exclusively treating Covid-19 patients, ca. 300 at a time; hospital has installed a triage to provide treatment only to patients with highest changes of improved/positive outcome
Internist, same hospital as (3)
Anesthetist from ICU in Piemonte (Northern Italy); two operating theatres had been converted into temporary ICUs to meet demand; in total 45 patients (15 per ICU), no turnover of patients for past two weeks

One part of the interview focused on understanding the doctor’s and healthcare worker’s current situation, the equipment and workflows to treat Covid-19 patients. We focused on gaining insights regarding the existing shortage of equipment or other resources, and the expected development and implications of shortages in case of an aggravation of the situation. The goal was to derive root causes for potential harmful situations and related needs to prevent these.

Another part of the interview was a discussion about a fictive monitoring system based on mobile applications for sensing of vital parameters and their visualization, to be used by patients and staff. We evaluated our proposed solution to find it’s drawbacks and misconceptions.

Scenarios

We focused on two main crisis scenarios where ICUs have been temporarily set up in operating theatres and reviewed how personnel workflows are affected by the crisis. The reviewal covers three main points: vital parameter data collection on the patient, data display to the medical staff, and workflow and work conditions of the medical staff.

Data collection can be split into continuous monitoring usually performed by bedside Patient Monitors and intermittent measurements of specific vital signs in regular frequencies usually performed by staff.

Data display is about how the collected data is analysed and made available to medical staff and doctors. It can be available when being at the patient, or if collected and distributed digitally available remotely.

Workflow and working conditions of the staff is about occupancy and stress-level of the onsite staff. Even in regular hospital workload, staff work are highly trained in their daily tasks and yet under high pressure from understaffing. In crisis situations this is exacerbated by factors like mismanagement, technical problems or training of inexperienced people.

Scenario #1: Minor Overstressing of Hospitals

In this scenario rooms such as operation theatres are transformed into temporary ICUs because of the higher need. We will use the word extended ICUs and expanded ICUs as synonyms in the following descriptions. These rooms have bedside monitors for the continuous monitoring of patients. However, the data collected by those is not sent to a central unit in most cases.

Scenario #2: Major Overstressing of Hospitals

This is an extension to the Minor overstressing scenario, assuming the amount of people to treat reached a point where triage becomes necessary.

The equipment situation in the regular ICU will not change, however with more doctors and staff having to take care of more patients overall, their time per patient will be much more limited.

This becomes worse in the expanded ICU. Given the makeshift nature, more nurses will be required to handle the load of patients and the additional work by incomplete or missing equipment. Having insufficient Patient Monitors adds work of recording and monitoring patient status. Having more teams also requires more structure within the organization. Students enlisted to support or retirees brought back into service require training and oversight before working effectively.

Thesis

We started this research with the premise of what benefit an app-based monitoring system in case of lacking Patient Monitors could bring.

Our assumption was that in the context of overstressed ICU’s alternative uncertified tools can support health care workers due to a lack of equipment or people power patients may be lost. The proposed mockup would provide Vital Parameters Monitoring to ICU’s not connected to central Patient Monitoring and allow to visualize the live data in both a central room or on the go on health care worker’s phones.

According to recent research conducted at Brno University of Technology and The Czech Academy of Sciences, smart phones are capable of sensing / estimating the following vital parameters:

heart rate (HR)
blood oxygen saturation (SpO2)
blood pressure (BP)

HR and SpO2 estimations are based on creating a photoplethysmogram (PPG) from the rear camera, BP can be estimated using the pulse transit time value calculated from the PPG and phonocardiogram (PCG) recorded using the microphone.

Other ongoing projects suggest that respiratory rate can also be measured using a smartphone’s microphone.

System setup

The software solution discussed in the interviews was a mockup not actually planned for implementation. As such, describing its structure serves to understand the conclusions learned. It’s not a blueprint to implement.

For data collection, patients would install a monitoring app for continuously recording their vital signs and submitting them to a central processing and database server. This backend would provide APIs for accessing the data for display. The server would also include heuristics to send warnings about abnormal or dangerous vital signs.

For display, we discussed the mockups of a mobile client with our interviewees. This would list hospitalized patients for a quick overview of each’s most important live sign reading. A more detailed view analog to the screen health professionals know from the standard Patient Monitors provided additional information and a log of treatments.

Evaluation

If not mentioned otherwise, any information shared in this chapter is based on the interviews as described in “Methodology”.

Status Quo and Needs in Monitoring and Treating Covid-19 Patients

The majority of Covid-19 patients are not in a critical state, some require support for breathing (i.e. non-invasive ventilation such as CPAP). After a potential triage in the emergency rooms of a hospital, they tend to be treated in a regular ward utilized for Covid-19 patients exclusively. The vital parameters of these patients need to be monitored 3–5 times per day, conducted by a nurse in a sequential manner. In case of a worsening health status and need for further interventions beyond medication — such as invasive ventilation — patients are transferred to an ICU. Discharge is linked to a good value of a patient’s peripheral oxygen saturation and needs to be done prematurely if too many patients require treatment.

If ICUs become too full, current practise seems to convert operating rooms into temporary improvised ICUs.

Medical guidelines may differ from current best practise (note: guidelines not researched here; best practices based on interviews, see “Disclaimer”), but here is a summary of the vital parameters that are most decisive when treating Covid-19 patients:

Non-ICU setting

oxygen saturation SpO2 (single most important value)
blood pressure
pulse rate
respiratory rate

ICU setting

oxygen saturation SpO2 (single most important value)
blood pressure
ECG
CO2 in exhaled air (if invasively ventilated)

Here, we can find a significant overlap with the parameters potentially sensed by smartphones (see: Thesis).

In regards to vital parameter monitoring, consisting of data collection (sensoring), data displaying (and transmission), and related work flows, the following situations and needs could be determined:

Scenario #1 — Minor Overstressing of Hospitals:

In this scenario temporary ICUs are used where bedside monitors are not connected to central monitoring units. This creates a need to manually check the vital parameters of each patient in a high frequency by a health worker and report them to other doctors or nurses.

To accomplish this a simple method of writing down all parameters on a paper by hand is used in one of the hospitals, reported by an interviewed health worker. The paper is then stuck to a wall where others can see the parameters to avoid infection by touching paper.

As more doctors are working in the temporary improvised intensive care units, doctors in the non-intensive care units need to monitor more patients as usual.

Scenario #2 — Major Overstressing of Hospitals:

In this scenario temporary ICUs are used where bedside monitors are not connected to central monitoring units. The high number of patients could lead to a lack of bedside monitors and other important data collection devices which amplifies the problem of being able to supervise all patients. Manually checking the vital parameters of each patient in a high frequency by a health worker and report them to other doctors or nurses takes now even more time and effort than in scenario #1.

Furthermore a lack of data collection devices in temporary ICUs could arise more easily. In this scenario the number of deaths will probably be higher because of the uncontrolled patients.

As more doctors are working in temporary intensive care units, doctors in the non-intensive care units need to monitor more patients as usual and have even less time to monitor them regularly. The number of available nurses and other health care workers could be insufficient because of the need for them to treat more severe cases of patients in the temporary improvised intensive care units. The probability of missing out the worsening of a patient’s state in the non-ICUs could increase.

For standard ICU units the ratio of available doctors to patients could also decrease which could lead also there to a lack of control and correct supervising of patients. However, in a slightly less problematic way because of the full equipment of bedside monitors and the central unit monitors which alarm doctors and other health care workers.

Independent from monitoring of vital parameters, the following concerns were raised as most pressing:

Shortage of ICU beds
Shortage of drugs and usage of off-label drugs
Shortage of ventilators. This would mean an even stricter triage.
Shortage of trained personnel (ICU nurses), possible reasons are:
personnel infected because of shortage of PPE equipment
further increase in number of patients

Further problems which arise are around a Loss of control, mainly due to understaffing. If patients cannot be monitored efficiently there is the chance of:

Missing out an alarm which brings the ICU patients into a life-threatening situation.
Delaying the admission of non-ICU patients into intensive care before it’s too late
Compatibility/Interoperability amongst different devices
Prototypical technology (e.g. smartphones) to display the data from side bed monitors in temporary ICUs could create an extra burden to health workers if they need to use them in addition to the commonly used data of the central unit screen.

Smartphones in Hospitals

In a regular ICU monitoring, systems are in place that don’t require additional app-based solutions. In the case of supporting overstressed expanded ICUs app-based solutions can provide benefits where the alternative is to do without.

Smartphones are an ubiquitous amenity for most people, in the daily business of a hospital they are not a regular tool. In the early years of mobile phones, they could even cause interference with medical equipment and where therefore banned. This is not an issue anymore, but phones remain a vector of infection and certain aspects of practicability need to be evaluated. One strength of the smartphone in particular is its versatility through applications utilizing internal or external sensors. Developing an app for reading sensor data from another device or directly from the patient is possible. Getting started on such solutions is not a manageable effort.

In normal circumstances, technology used in medical wards requires a long testing and certification Process. Functionality and user interfaces are standardized and reglemented to facilitate the training of health personnel.

Hospitals handle phones with their employees differently. Some allow phones for notes and look up. Usually phones are not connected to the hospital’s internal network.

Other hospitals are more strict and regard phones by default as contaminated devices not to be brought into wards.

When using a patient’s phone there are three obstacles to overcome. The phone needs to be prepared and the correct software installed for the monitoring. The patient needs to be trained how to use the app correctly. Secondary infrastructure such as power source for the phone or reliable Wifi for data transfer needs to be available to ensure smooth function. Each is critical and if something is not working, it requires health care people to support that is required for more critical tasks.

Reliability and Trustworthiness

In order to have successful use of the system, it needs to be reliable. Staff will be busy doing their regular work and can not afford to second-guess if the shown data or the given alerts are correct.

In order to achieve reliability the system needs testing before deploying it in an emergency. Testing systems beforehand is difficult and hard to do during an emerging crisis. In our setup, critical infrastructure is power supply of the phone and network availability.

If the system relies on patient support — for example by holding the app in a special way — usage mistakes need to be avoided. What if the patient is not cooperative or has no phone available.

It’s important to identify and review assumptions where you have to assume goodwill or ideal circumstances. People will be stressed and things may fail, and failing things will cause more stress.

Health care workers are not against adopting new technologies, if it supports them in their job and does not get in the way.

They are used to professional licensed medical equipment and they will prefer it as long as the situation and capacity allows. Should make-shift measures get introduced, the lack of space and level of exhaustion will have everyone already stressed out. Staff may prefer not use such a solution if it causes more distraction and confusion than it helps to save lives.

Feedback on Mockups

In order to test our initial assumptions, we created clickable prototypes of an app to gather more specific feedback from the doctors and health care workers in the interviews.

In the first version, the feedback was generally positive. The interviewed doctors showed a positive reaction of using their smartphones for being able to monitor patients on the go or when convenient. However it became clear that doctors are very accustomed to the view of traditional monitoring devices in hospitals. Hence the visual design had to lean more against them. Therefore, we moved to a UI in dark mode for the second iteration and used a more conservative visualization of graphs and colour coding.

We also learned that the data that’s relevant for doctors varies significantly depending on the state of the patient. For patients who can still breathe by themselves or with oxygen support, data like the oxygen saturation and blood pressure are more relevant. With intubated patients on the other hand, it is more important to see the settings on the machines.

As for the sorting of the list in the patients’ overview, we learned that there are two types of alarms: red and yellow. A red alarm is the most critical one and occurs for example if a patient stops breathing or his / her heart stops beating. These patients must thus also be displayed at the top of the list as their state is the most critical.

Alternative proposals

While evaluating our proposed solution, alternative approaches were discussed. They are not detailed, but describe some requirements and solutions that could warrant further attention.

Requirements

Something all solutions have in common is, that they need practical testing before the actual deployment in a disaster situation. Even during a pandemic like Covid-19, not all areas in the work are affected the same and solutions can be tried in places where outbreaks are not imminent yet.

The reliability and scalability of the process or the technology needs more testing. This applies both to the infrastructure, hardware and software, as well as training, deployment and monitoring.

The solution should have the least amount of assumptions. Integration and use needs to be testable and be monitored to evaluate its effectiveness and discover potential for improvement.

Engineers tend to see a problem and want to fix it with technology — sometimes solutions with simple proven technology are the best for the job. Reflecting if Pen and Paper work better than an App is necessary to put the outcome over the solution.

In the end, it has to make life easier for people. If it is no help, it shouldn’t be used in disaster.

Compensating Shortage of Ventilators

A single ventilator may be quickly modiﬁed to ventilate four simulated adults for a limited time.

Related Video, explaining the concept: https://youtu.be/uClq978oohY
Related study: https://onlinelibrary.wiley.com/doi/epdf/10.1197/j.aem.2006.05.009

Smartphone Webcams for data visualization

A simple solution would be to use the webcam of a smartphone (maybe the patient’s smartphone) to record the screen of the bedside monitor. Every few seconds the latest image of the screen of each patient will be displayed on the smartphone of the health care workers after selecting the specific patient. A special holder would be needed to place the smartphone camera pointing to the right direction and to record the full monitor. The battery on the phone at the bedside monitor could be charged constantly in place.

The disadvantage of this solution is that a regular check of health care workers on their phones is still needed, since they would not get notified by alarms from the bedside machine.

Specialized standardized Emergency equipment

Ideally, a specialised low-resource Emergency kit for Patient Monitoring could be developed with the potential dual use for disaster relief efforts. These kits would either be cheap and fast to produce or small, durable and cheap to stock. Open access to data interfaces would allow external applications and services to hook in to provide expanded functionality at scale.

Handling would be standardized and staff would receive limited bi-yearly training to refresh usage. This would be the go-to solution for quick scaling of Vital Parameter monitoring.

The author’s did not research availability and quality of existing emergency kits. No such usage was documented in the interviews.

Conclusion

In times of disasters or crisis such as the COVID-19 pandemia, it becomes even more crucial to determine the problems where solutions would have the highest positive impact on the overall situation. It can be key, more than ever, to involve people from the “front line” early on in the problem finding and ideation process and to take a human-centered approach when designing solutions.

Although the reaction of the health workers was positive to the proposal of using prototypical technology such as a smartphone for vital data display in temporary ICUs, it would need a deeper analysis and testing of a prototype in the real world.

Doctors were very hesitant when considering the option of using smart phones to actually sense vital parameters. Here, it needs to be assessed even more carefully if this path should be taken, if this becomes necessary, or if there are other possibilities to monitor and treat patients with approved equipment only while scaling up capacity.

Attachments

Interview Questions

Understand their background

Title/Role
Clinical Setting
Have you been involved with Covid-19 patients so far?
Are you preparing for a run of Covid-19 patients?
What are your top 3 pressing concerns right now?

Patient Journey

Can you talk me through the process when a Covid-19 patient comes into your ward?
Talk me through how you would monitor a Covid-19 patient throughout the time in your ward?
What changes do you expect in these processes if you would need to deal with hundreds of patients at a time?
If you were to deal with hundreds of patients simultaneously, where and when would it be most likely that you lose control? What part of the patient journey and for what reason?
What about temporary rooms which are used now because of missing beds and space problems? How are people monitored there?
If we could organize one thing for you, to ease your load on the ward, what would it be?

Vital Parameters

If you could get only one vital parameter of each Covid-19 patient, which one would you take?
What other two pieces of information are most crucial?
Based on what vital parameters do you take most of your decisions and how do they need to be presented?

General

Are you currently using equipment that is not CE marked? Could you imagine to use such equipment during a crisis?
For what kind of patients would you use monitoring of patients via mobile phones?

Mock-up related questions

Please describe what you see
How often do you usually check a patient’s vital signs?
Is the provided data in the home screen enough for health workers to understand the criticality of a patient’s conditions?
What is the important static data a doctor needs to have access to on the go?
What dynamic data is important? Heart rate, oxygen levels, CO2?
If you need to go deeper than the information provided on the home screen, what information would be helpful to you?
How realistic is it for you to use an app in such conditions?
What could potentially stop you from using it?
Is there anything else you’re missing from the app?
Is there anything else you’d like to tell us?

July 7, 2019March 29, 2025

Words are the glue — Setting up cross-functional teams

In our company, we experimented the last year with various setups of Cross-functional teams. These teams consist of members from different departments for a limited time to implement a specific goal. They do not have to be IT-focused, but coming from an IT background my experience is from being in and leading IT- and Product-focused teams.

If you are reading this setup guide, chances are high that you want to set up a new Cross-functional team. Awesome! This guide should give you a hand in where to start and what the main questions you and your team should discuss are.

Goal

What is the goal of the team? Most likely, it’s an implementation requiring close communication and high-level understanding of a specific domain.

When organizing the team, be clear what is expected of the team. The scope needs to be known by all in the team and by all external stakeholders.

In the first two weeks, bring it up often and repeat, so everyone can align on this. Repeat one time too often, rather than not enough.

Depending on how clear the goal is, it can be helpful to define a mission statement everyone can agree on. In discussions about the team’s direction, this can serve as a compass.

What is the goal of the team?
What are the must-haves and what are nice-to-have’s?
Which deadlines exist?
When does the team regularly end and how?
Under which circumstances can the team end without reaching its goal?
Can the goal be summarized with a generic mission statement?
And lastly, the fun part: what’s the team name going to be?

Side topics

When defining the scope, you will find topics that are core to the implementation and topics that are on the side — still on topic, but not required in the MVP. Identify those and put them on the side. It helps being aware of these topics and in discussions about scope, it is good to be able to point to this list to not get distracted. Over the course of the team’s existence, these topics may be revisited, as they gain more importance or as they become valuable as filler work in case the core functionality requires waiting periods.

Where to draw the line between core goals and side topics?
What freedom has the team in defining or redefining the scope?

Organization

Past cross-functional teams in my company have all tried to follow an agile approach, but it was up to each team to define what they meant by this. Some teams chose a structure like Scrum, others went for Kanban. If the team’s goal is well-defined with a deadline, even an approach similar to Waterfall is possible and can serve the purpose. Of course, hybrids can also be discussed. This can be interesting when it comes to communication and rituals. More on this later.

Does the team want to work towards one big goal?
What milestones can be identified?
Can the work be broken into iterative steps?
What steps depend upon each other?

Reporting

The team was set up for reaching a goal and somebody is interested in the progress towards this goal. There may be multiple stakeholders that need to be kept in-the-loop:

departments and their heads requesting the feature
management or execs
maybe a department is affected in case of success which is otherwise not involved over the term of the cross-functional team

Identify who needs to get what kind of updates and how frequently they should be updated. Schedule regular updates, so they don’t have to ask and can trust to get informed as the team moves ahead. This can be meetings, but — if agreed — updates by mail or other means may be fine as well.

If your IT developers have Sprint Reviews, ask to use this platform to inform a wide range of people about your updates.

Who requires knowledge of the progress of the team? Which departments, heads, management members?
How often should they be informed?
In what format do they want the updates?
Can the work presented in the IT Sprint-Review?

Roles

Whether the team is set up with one Tech Lead coordinating its strategy and implementation or with a flat hierarchy may be outside of the scope of the team. If this was not defined, it is up to the team to agree if they want to have a layered or flat hierarchy. In smaller teams, flat structures proved working fine.

One recommendation for teams with flat hierarchies is to define roles within the team. Roles may emerge automatically from the tasks, i.e. Developer and Project Manager. Even within a group of developers you will find small-scale responsibilities that are worth talking about in the team.

Either way the hierarchy is set up, the team should have one person who is the first contact for outside stakeholders. She should receive and distribute messages from and to the team. This does not mean, other team members are asked to not directly communicate to outside stakeholders, just that the team contact should be aware of the communication. Summaries are best practice.

The team can decide to assign one member to attend the stand-ups of the IT-Dev teams to be aware of their topics and identify when topics of both teams intersect. We are going to talk about the importance of retrospects below, organizing them could be another task for one team member. Another role could be somebody to remind updating tasks and tickets.

During the existence of the team it may happen that somebody goes on vacation. Remember to prepare handovers and assign replacement(s) for the roles in vacation.

What is the hierarchical structure?
Is there one Tech Lead or a flat structure?
Who is the first contact in the team?
Who organizes meetings like retrospectives?
Is somebody interested in attending the Sprint Standup?
Who is responsible for taking care the team keeps updating their todos and status?
Does anyone have leave planned during the existence of the team?

Documentation

Setup a Confluence/wiki page describing who is in the team, what the goal is, and how you organize yourselves. Any decision the team makes about its structure can be noted there.

After the team is done, this page is also helpful for documenting how the team was set up and about the learnings of the speedboat.

Who is responsible for taking care about the care setting up and updating the team’s Confluence page?
What topic should be documented?

Meetings

Be aware that different team members work on different schedules. People with Manager’s Schedule have their day split into many blocks due to meetings and context switches. People in Maker’s Schedule tend to have an empty calendar with long blocks working on one subject without distractions.

The team should discuss which regular meetings it deems useful.

Perform regular retrospectives within the team, to have a safe place where anyone can bring up a topic.

If your team lacks people experienced with facilitating this kinds of meetings, think about calling in outside help to get you started.

What daily or weekly update meetings does the team want?
How regular should retrospectives be scheduled?
Who wants to facilitate the retrospectives?
What meetings of the IT-Dev team does the team want to attend?

Codebase ownership

This topic very much depends on how the IT-Dev team and the cross-functional team are aligned on their goals.

The recommendation is to separate the codebase the team has to touch from the codebase the ongoing IT-Devs will work on. For the duration of the project your team may get temporary ownership of the codebase. The Dev-team may still do changes, but has to check-in with the team to ensure their changes don’t interfere.

Circumstances may demand both teams to work on the same codebase, which should be reflected in closer communication between the two teams. This includes talks about intentions (what does each team plan to do next) as well as review (reviewing each other’s contributions). Think about attending each other team’s standups, sprint plannings and inviting members of both teams to pull requests.

Which applications are included in the project scope?
Can the cross-functional team take ownership of these projects for the duration of the project?
How should the two teams announce, review and publish their work when working on the same codebase?

Communication

In the last few sections many aspects of communication were already addressed. The experience with previous teams was that this is the topic that can cause the most friction within or outside the team and motivated this document in the first place.

Difficulties within the team can be around ticket status or their lack of updates. Depending on the structure, pair programming may be encouraged to share knowledge and help problem-solving. Mix the pairs frequently, if two strong programmers pair often, they may progress rapidly ahead of others, making it hard for the rest of the team to catch up.

Define with your team how to handle people working remotely.

Make it clear, who to report to in case of sick leave. At the very least HR needs to be informed, writing to other team members is a courtesy.

Summaries (for example in confluence) of what happened when team members were out due to vacation or sickness are generally appreciated.

What are the expectations about announcements and visibility of Home office?
Who takes care of writing a summary when members return from leave?

Ending the team

The nice things about temporary cross-functional is their limited length. You can specifically plan the teams deadlines and use the last week for cleanup, handovers and documentation.

Have one final retrospect about the term of the team — and make sure you have a nice party! Document the topics the team worked on and the lessons learned in your team’s Confluence page. Talk with the IT-Dev-team, as they are likely interested in a summary of the team’s experience.

Similar to the beginning, it is important to align with the stakeholders again. Have meetings with the relevant departments to present how the team’s goals were met.

The scope of these presentations depends on your audience. Most departments are fine with a higher level explanation, while the IT-team will appreciate technical details.

Evaluate if the cross-functional team was worth it — afterall it is an expensive approach and answering this questions helps to make the decision, to setup a new team, easier next time.

Was everything done as expected?
What might be missing?
How do you deal with remaining side-topics?
What changes had to be decided on?
What departments should be informed about the results of the cross-functional team?
What are the lessons learned (technical, data or process-wise, organizational)?
How was the mood in the team?
How did the other team feel with you gone?
Was the team worth the effort?

Final remarks

Take everything I described here as a recommendation. The team you setup will be unique and is free to make their own choices. Feel free to come up with ideas that are not documented here.
Cross-functional teams are a great way of experimentation!

Category: Product Management