Remote Alienation – It works without!

Digitization and the associated integration of IT and software components, demand in a specific IT discipline is not only growing linearly but rather exponentially – in quality assurance! Scarce office space, an increasingly difficult recruiting situation and the lack of innovation in the image of quality assurance clearly exacerbate the problem.

At first glance, the use of external QA consultants appears to be the solution, but at second glance it also presents some hurdles:

  • Due to new legislation (employee leasing law) there are consequences in terms of labour law when using one or more test experts; the proximity to the customer and the integration into the customer’s test processes leads to the leasing of employees and the resulting in organisational and legal consequences.
  • If the test team is to be deployed directly at the customer’s premises, it is also necessary to make office space and the corresponding technology available to all those involved
  • The necessary budget must be provided for an external test team. The on-site activity of the external test team or external test experts increases the budget
  • Due to the current situation on the labour market, it is becoming increasingly difficult to find employees for internal positions as well as for external service providers, who are prepared to relocate to the project location or are willing to travel

The solution here is an external test-centre, which supervises the necessary tests remotely. The following advantages of a remote deployment for the customer:

  • Lower costs for the test service, as travel and accommodation costs are eliminated
  • Higher scalability of the test personnel, as the service provider can optimize its utilization at one location and thus guarantee the customer greater planning reliability in the provision of resources
  • By concentration of the personnel at less locations, more know-how carriers and experts are available for special assignments
  • Centralization keeps the test teams stable, which reduces the fluctuation of acquired domain knowledge
Figure 1: Collaboration at different locations

In addition, the service provider can open the test-centre at a location with a strong and stable employ supply base. In this way, he can find suitable employees and retain them for longer.

However, the use of a remote test team/test-centre or the physical separation from the customer creates a new problem, the so-called remote alienation. This is expressed by the following symptoms:

  • Speed disadvantage due to technical and communication hurdles
  • “Faulty” coordination leads to deviating test results (from customer expectations)
  • A lack of transparency leads to a loss of trust in the test results for the customer
  • Due to the physical separation, the testers have limited opportunity to collect the customer’s domain knowledge, which can lead to incorrect test procedures despite good test expertise

To counteract remote alienation, we have developed an approach that has the advantages of a remote test centre or distributed test teams, but tries to keep their disadvantages as small as possible.

The approach consists of optimizing our customer-oriented test procedure for remote or distributed test deployment and using ETEO, our working concept for distributed teams already established in software development projects. This involves setting up a small on-site office at the customer’s site as well as workstations at our sites (remote office).

The process model of our customer-oriented test procedure consists of three phases: planning, transition, and actual service support. In the planning phase, the feasibility is checked, and the contractual matters are regulated. 

Process model against remote alienation
Figure 2: Process model against remote alienation

The focus is both on a project with customer proximity and on a remote approach to transition.

In the first step, our IT experts and those of the customer are involved. Together they identify the technical framework conditions such as remote and system accesses as well as authorizations and connect the “on-site office” with the “remote office”.

At the same time, the customer’s test managers coordinate with our test task force (our test manager and test analysts). The tasks include getting to know the customer’s domain and organization, organizing the setup of the remote team (TM) and setting up the “on-site office” and the “remote office”.

Basically, the testers work remotely from their home location, but as part of the transition, a minimum six-week training period takes place at the customer’s site. On the one hand this enables the testers to get to know the customer and his processes intensively and on the other hand it also allows the customer to get to know the test team. The basis of the training is an explicit training plan, which is created by the test manager and reviewed by the customer.

During the actual service support, additional tools are used to counter remote alienation. The first tool is the test task force, which consists of our test manager and the test analysts. Despite the remote focus of the project, a significant part of these analysts are located at the customer’s site. Various scenarios are used: The test manager is on customer’s site at least two days a week and the rest of the time he supervises the team. In peak times or on important occasions, the test manager stays at the customer’s site longer. For the test analysts a similar setup would be conceivable. However, it is also possible for the test analysts to alternate between on-site at the customer’s premises and in the remote office (e.g. on a weekly basis). The test analysts largely require the same know-how (domain knowledge) to be able to represent themselves in an emergency. By visiting the remote office, the test analysts automatically transfer their knowledge to the testers. Test analysts can also be on-site at the customer’s premises for longer periods or even simultaneously during peak periods. This concept can save 25 % in travel expenses.

A second aspect in reducing remote alienation is the use of ETEO. ETEO – Ein Team Ein Office (German for One Team One Office) is our innovative concept for distributed cooperation and a modern form of collaboration where all participants can work together on a scenario from different locations. 

Entwicklerteams an zwei Standorten
Figure 3: Distributed collaboration at two different locations

Through the targeted use of technology, methods and personnel trained for this purpose, a procedural model has been created that reduces travel costs to a minimum, and which sees transparency over all cycles of the test project as its top priority.

Verteiltes Daily
Figure 4: Distributed Daily

Part of the ETEO concept is a short distributed daily meeting, the so-called “test thing”.

The aim of the daily meeting is to report the status, name impediments and plan the day. Thanks to the technology of the ETEO concept, all parties involved can participate on site and in the remote office. An electronic task board (eteoBoard) is used to coordinate the daily planning.

At the remote locations, a periodic knowledge transfer (e.g. every 14 days) for all team members takes place. In addition to exchanging and building up knowledge, these meetings also serve to conduct retrospectives to document any problems that may arise and to improve the testing process.

Distributed collaboration - test thing
Figure 5: test thing

In addition, other tools are also used. With regular status reports by the test manager, transparency is achieved not only for the customer but also for the entire team. This transparency is enhanced by the creation of a dashboard, which, based on the test management tool used, displays important key figures for all those involved, in agreement with the customer.

In almost all industries along the IT challenges, but especially in QA, the necessary scaling has become the number one problem. Even reinforcement by external resources is not always possible on the one hand and/or brings new challenges on the other hand. One solution is to have well-rehearsed teams to turn highly qualified quality assessments of your software into continuous services.

With the described approach, it is possible to access the resource pool of scalable locations, such as Leipzig, Dresden, or Miskolc, and escape remote alienation by using the appropriate tools and procedures.

Software Development in Corona times – Business as usual?

While observing social distancing, video conferencing with friends has replaced going down to the pub. During one the subject of how corona influences our work life, popped up very fast.

The consensus was, that the ability to work was greatly impacted and that for some it even had completely disappeared. Their employers were simply not able to supply the necessary infrastructure. And even after the infrastructure eventually was set up the reality set in: It is complicated! Who may talk? Camera on or off? Please mute your microphone the kid is screaming in the background! You want to talk? Please un-mute you microphone! The connection is bad I only get every second word… The list is endless.

People simply are not used to working like this. Not least, because communication is more than exchanging words. During phone and video conferences the interpretation of body posture, facial expressions and gestures is far harder. That is a new situation, which requires great discipline and change in behaviour by all participants!

The discussions carry on and they alternate between reviews of video tools and how working in this situation is impossible. Meanwhile I am frantically searching for something to add to the discussion. But no matter how much I search, I only find one answer to the question “What has changed in your work situation since COVID-19?”, “Nothing really“.

Admittingly that is a slight exaggeration! The commute, the collective lunch break with the colleagues, the chat at the coffee machine – all this currently does not take place, and these are drastic changes and great losses. For people like me where home office is also a day-care and both parents work full time, distributed work can become quite a challenge.

But even in this situation the starting point is the same for everyone. So, you only have the choice to accept it and make the best of it. This shows how important it is to have gathered experience with working in distributed settings.

ZEISS Digital Innovation (formerly Saxonia Systems AG) has been following the basic principals of working in distributed teams for years. Not least to ensure a healthy work-life balance for the employees, it is important for companies to ensure that services can be provided from basically everywhere. This keeps travel expenses low and ensures that the necessary infrastructure does not have to be provided by the customer.

Person sits in front of a laptop and severals screens during a video conference using the ETEOboard tool for distributed collaboration
Figure 1: Distributed project work from a home office

During the five years that I have been working for ZEISS Digital Innovation I have only encountered one project, that united the complete development team at one site. My current project, that was started in September 2019, is extremely distributed, the six project members of ZEISS Digital Innovation are split between five sites and the project stakeholders are at two sites. Therefore, the distribution existed pre-COVID-19 and was identified as a project risk to be addressed.

In my view this was achieved with a simple sounding solution: direct communication.

The developers often used pair programming to not only ensure knowledge transfer, but also to get to know the programming style of the other developers. Apart from this, code reviews belong to our standard procedure. These are not only a quality assurance measure, but also distribute knowledge throughout the team. Beside the daily meeting for all project members, we also have established a “DEV-Daily”, in which the developers can focus on mainly technical issues.

Business requirements are mapped to technical solutions during regular refinement meetings. Ideas are collected, checked, adapted, discarded and created in no-holds-barred discussions. This leads to an area of creativity and free development, that all team members can contribute to, which in turn feel valued and included. Even during the distribution of the team, a real team spirit has developed!

The establishment of this open communication culture has led to a more intensive and frequent communication within the team. Be it one-on-one or in a larger group. One must always carter for the preferences of the individual team members. Some are early birds, at 8 o’clock they are fully in their flow, bursting with ideas to present to their colleagues, some barely can open their eyes at that time in the morning. Some need planned meetings to have time for preparation, others easily hop between subjects and you can call them anytime.

To be honest, it is not enough to simply communicate more, to work efficiently in a distributed environment. Rather an elaborate concept is necessary, that takes all the aspects and challenges of distributed work into account. This is especially important for teams with little experience with distributed work.

Several years ago, ZEISS Digital Innovation already received attention with their ETEO-concept. ETEO (“Ein Team Ein Office” – One Team One Office) is a framework for distributed work in teams. It gives project teams a guide as to how distributed work can be achieved. A permanent video link between the sites and a digital work board for task assignment enables the teams to work spread out between different sites. Just like being at one site together. The video link is no requirement it is just a building block from ZEISS Digital Innovation’s toolkit for distributed work. There are specifically trained employees (ETEO-Coaches), that train and coach the team members, in techniques for distributed work, during ramp up and the project duration. It often leads to a “aha moment” with our customers that distributed work without performance impact can work.

Graphic of a house "One Team One Office" on four pillars based on the values for distributed scrum teams
Figure 2: ETEO (“Ein Team Ein Office” – One Team One Office) – Our Collaboration Model

In general, as with everything the rule applies, the tool is nothing, if you do not know how to use it. With this I mean that distributed work can only work with the discipline and right mindset of the involved. One thing is left to be stated, you have to commit yourself without reservations and just try the tools and techniques. And of course: Practice makes perfect. The longer a team works in a distributed environment, the stronger the best practices for distributed work are highlighted in the individual team setting. One must not forget that there is no such thing as the ultimate concept for distributed work. Interactions within projects are not between roles and responsibilities but between people and they are all different.

Each project is different and therefore also the requirements for distributed work. But the basic principles are basically the same. This can be compared with building a house. No matter how it looks, number of floors or type of roof it has, it always has a foundation it rests on.

The foundations of distributed work at ZEISS Digital Innovation are sound.

The Routine of a Distributed Team: A True Team with Authentic Values

In this blog post, I would like to talk about my personal experience working in Saxonia Systems (since 03/2020: ZEISS Digital Innovation) first distributed team in Dresden and Miskolc, Hungary. The exciting thing about this is that 60 people located almost 1000 km from Saxonia Systems head office can work on the same project as the colleagues in the office next door, and yet they are a true team. People who do not have experience working in a distributed team will probably have some difficulty understanding how this type of collaboration works. I am writing as the scrum master of a team, half of which is located in Dresden, the other half in Miskolc, Hungary. This blog post is meant to show how we started working together, and how we gained the trust and courage to build this team.

Initially, the team consisted of the following people: Three developers and a business analyst from Dresden, and three developers and a scrum master from Miskolc. The German half of the team had already been working on the project, but there was still a lot of work to do before the deadline. At the beginning, we all had different expectations in the collaboration: At first, we were afraid of the camera on the wall. How are we supposed to work when someone is watching us all day? How is a distributed team supposed to work when our German language skills are not that great? How are we supposed to work with colleagues who are that far away?

People standing in front of a screen during a video conference in a distributed team
Figure 1: Brief discussion in the team

Time was short, and we quickly set up the offices according to the ETEO concept. Once the basics had been established, we met in person for the first time. The trip only took a few days—just enough time for us to get an idea of the project together. We thought, now that we had met in person, there was no more preparation left to do—we all liked each other. So now we should focus on the project start, and that’s that. However, we soon realized that it was not going to be that simple.

We came to realize that the permanent video connection is not the solution for distributed work, but merely a tool that helps the team in their work. It is great that we can see the others all the time, but nobody had the courage to stand before the TV. How could we expect team members who had met only once or twice to have the courage to ask a simple question in front of the entire team? More likely than not, the answer would be “I don’t want to bother the others. Instead of asking them, I’ll just google the problem, right? If I’m lucky, I’ll find the answer quickly; worst case, I’ll spend hours on this.” I think it is obvious that the team cannot afford losing that much time in such a situation if they want to be effective.

I believe that this kind of courage grows in people if we are able to approach and start to trust each other. It is not easy to build trust without meeting in person, talking casually, having dinner together, and undertaking team-building activities. Based on my experience, I can say that what really helped us build a true, geographically dispersed team was the possibility to travel back and forth between the locations in the early stage. Team members need to be able to sit next to each other; they need to be able to feel like a team, not just like people working together on something. Later, meeting once a month or every other month is enough. Still, that should be the maximum interval because the connection has to be maintained; otherwise, the team’s productivity diminishes.

Smiling people sitting at a dinner table on a terrace.
Figure 2: Team-building dinner

Being agile is another important objective. That may sound cliché, but it helps the team to evolve and demonstrate their individual values. Below I will describe a few examples that helped us get where we are today.

For example, we started working with new technology that not all of us were familiar with. In the past, we used to try and share knowledge in pair programming sessions because we did not have specific scrum meetings for this kind of activity. As a result of a retrospective, we found that we needed to organize “Developer Cafés”, weekly meetings where we sat together and exchanged our knowledge of the selected issues within the team.

Learning German is another example. Our project language is English, but the team decided to speak German in the daily stand-up meetings because they wanted to learn the language. You might think that this was only difficult for the Hungarian colleagues, but that is not true. It was a great challenge for the German colleagues as well because they had to speak more slowly than usual, and be careful to use simple sentences.

People sitting at a long conference table in a meeting room
Figure 3: Workshop in Dresden

This kind of thing is usually the result of the retrospective, the most important scrum ritual in the team’s life. We have to resolve our problems within the team and improve. This is the best opportunity for the team to evolve. In this context, it is very important at times for the team to be able to do a retrospective together in one location. Personal meetings help to strengthen the bond within the team—this is my most important advice. Because over time, the team will evolve, provided that they are encouraged and feel that they are a team.

What Used to Be Lone Warriors Is Now a Team – A New Way of Collaborating

IT consulting has always been an interesting business area. The advantage for the client is that they can schedule the workforce flexibly according to their technical know-how and capacities. Consultants have the unique opportunity to gain a lot of professional experience in a very short time because the project work allows us to get to know and actively shape a wide variety of client scenarios and work environments. We track new technologies and help our clients integrate them into their processes. Current issues we are dealing with in our software and quality assurance projects include Java, .NET/C#, cloud, web, mobile, usability, and agile methods.

Until 2010, working at Saxonia meant almost exclusively spending most of the week in the field, at the client’s premises somewhere in Germany, either alone or with colleagues. Unless you were fortunate enough to work on a project somewhere near your home, this was usually detrimental for your private life. At the latest, by the time you wanted to start a family, you had to ask yourself what would become of your career.

This changed at the end of 2010. Saxonia started its first project with a distributed team. With large screens and cameras, we started the experiment:  Even though we were in different rooms in different locations, we wanted to create the impression of being in the same office and working together on an agile project team. It was a rather bumpy ride at first, when we were still using an analog task board, and the connection kept breaking down. Furthermore, our understanding of what agile truly means developed slowly back then.

People sitting in front of two big screens on which you can see, first, another team in a video conference and, second, a list of tasks.
Figure 1: Distributed meeting in two locations

But our distributed agile collaboration according to the scrum methodology improved steadily, with ever-improving technical set-ups, with our digital task board, and last but not least, with our integrated concept for distributed collaboration, “ETEO” („Ein Team Ein Office“ – One Team One Office). IT consulting at Saxonia evolved, away from individual assignments and towards true project and team work with our colleagues.

Today, many of our daily project routines and travel activities have changed. At present, 84% of the Saxonians work at the office at their home location.

Map of Germany and Hungary with locations of the customer and ZEISS Digital Innovation
Figure 2: Distributed collaboration with customers at different locations

Most of us are now organized in agile scrum teams, working as a distributed team from Saxonia’s locations with the client and our colleagues.

One Team One Office - Collaboration at location A and B
Figure 3: One Team One Office – Distributed collaboration at two locations

In everyday life, this means that we work in offices that are connected to another location using state-of-the-art technology, allowing us to see each other whenever we want as if we were in the same room. Similarly, for our meetings, we stand or sit in front of the camera as a group. One-on-one meetings, e.g. for pair programming sessions, can be done at our own computer with a headset and split screens, enabling us to work comfortably together on the same task as if we were really sitting next to each other. For creative activities during the sprint or the retrospectives, we use digital whiteboards or notice boards that allow us to work together on the same surface.

A distributed team is working together in two locations with video conferencing.
Figure 4: Ad-hoc discussion about a task at work – no problem with video-conferencing

For the current project, we only travel to the client or one of the other locations, e.g. for the changeover between sprints, every 2 or 3 weeks, and sometimes even less frequently. IT consultants often used to be “lone wolves” working at the client’s premises. Today, they travel together with their team members.

The focus of our continuous improvement has not only been on distribution. In addition to the project work in teams, we have taken another step since 2010:  Collaboration and leadership have been rethought on the management level, too. This has continuously evolved into our agile strategy process that we consistently apply. This way, our entire company has gradually become more and more agile. Every one of us can contribute to this process by participating in so-called “Strategic Initiatives”. Today, the strategy stand-up (similar to the daily stand-up in scrum) takes place every other week after our joint “Pizza Friday”, distributed over all our locations using ETEO boards and video-conferencing. On these occasions, everyone can catch up on the current status of the Strategic Initiatives.

Couples Therapy – Successfully Integrating Service Providers

In a survey carried out by Capgemini (Capgemini Consulting, 2016), the respondents stated that the biggest obstacle for digitalization in their company was “Too few employees with relevant know-how”. It is not uncommon to try and overcome this problem by integrating one or several external service providers. The same survey furthermore shows that these service providers are increasingly used in areas or projects where innovative solutions are to be developed. It is likely in this context that an average 23.3% of the respondents already use agile frameworks, methods or philosophies such as scrum, Kanban, DevOps, or the Scaled Agile Framework in their projects.

As a service provider, we have already been relying on agile methods for a long time. Since 2013, we have formed mixed teams involving the client and the service provider according to our concept of distributed agile development, ETEO (German for “One Team, One Office”), and we provide tools and good practices to assist these teams during the initial unfamiliar work situation. The concept uses the results of a survey of our teams that had already been working according to this model, and it was subsequently further developed on a scientifically sound basis by a cross-functional team, with new findings from our teams continuously being integrated.

In our case, the team is assembled in a project room. The physical rooms (typically 2-3) at the distributed locations are connected via permanent video conferences. Each location preferably has an 80 inch screen, creating the impression that you see the other part of the team through a window.

A tool that we work with both in our teams and in external coaching sessions is the ETEO Value Compass, which combines the five scrum values of openness, commitment, focus, respect and courage, along with additional values that appear to be essential, particularly, but not only in distributed teams: identity, trust, empathy, collaboration and simplicity.

During the coaching, we usually ask the teams which of the values is most important to them. Not surprisingly, many of them say that the value of trust is most important. In his book “Five Dysfunctions of a Team” (Lencioni, 2002), Patrick Lencioni stated that trust is the basis for any kind of collaboration in a team. And ultimately, the individual values also appear to affect each other. Openness in the team, for example, creates trust. And with scrum, where it is not the individual contribution, but the team performance that counts, committing to a common sprint goal is possible only if everybody trusts everybody else.

But how do you build trust in a distributed team that rarely meets in person, where a little misunderstanding cannot easily be resolved over lunch or a cup of something hot in the communal kitchen? Unspoken issues can quickly spark conflicts, disturbing or completely destroying the trust within the team.

Couples therapy

This is why it is particularly important to get to know each other during an extensive, 6- to 8-week attendance phase, during which you learn to assess each other. Written, asynchronous communication, e.g. by email, can easily cause misunderstandings. The permanent video conference has proven to be highly useful in this context because it allows everyone to see who is present and how they apparently feel. Still, even with a video conferencing system, you should be careful not to use it exclusively for the professional exchange. Once trust has been damaged, it is surprising to see how even a small verbal or non-verbal signal can cause what is left of the trust to be completely shattered. In one of our project teams, for example, the team members in one of the locations used to lean back against the table behind them during the video conference for the daily scrum meeting because it was more comfortable for them. The colleagues at the other location, however, stated that this appeared as a threatening front to them. Such misunderstandings happen in particular if you fail to invest in strengthening trust, and the team does not meet in person at regular intervals (every 6-8 weeks).

Doing each transition from one sprint to the next at the same location is even better. This also offers an opportunity to do the sprint retrospective in one room together—a serious advantage in a meeting where the trust within the team generates a significant added value. Trust is the foundation for mutual respect and for the courage to realize the potential for improvement within the team with creative, innovative solutions.

Working with a common value system is just one of the challenges you face when you want to integrate an external service provider. We will address this issue in more detail in our presentation “Darling, I’ve met someone new – Successfully integrating service providers” at the solutions.hamburg conference. The track „Couples Therapy 2.0“ provides additional exciting insights and therapeutic approaches from the intriguing field “IT meets business”.

References

  • Capgemini Consulting. (2016). IT Trends 2016. Retrieved at capgemini: https://www.de.capgemini.com/resource-file-access/resource/pdf/capgemini-it-trends-studie-2016_0.pdf
  • Lencioni, P. (2002). 5 Dysfunctions of a Team. Jossey-Bass.