ZEISS further strengthens its engagement within the global FOSS community

Since many years Free and Open Source Software (FOSS) is a key methodology when it comes to innovative software development and has enabled software ecosystems to thrive. At ZEISS, FOSS is omnipresent. No matter if it is used as enabler within our daily workflows or as essential ingredient to our high-technology, software-based product portfolio.

Voluntary work and public sharing

The underlying public and collaborative software engineering approach allows solving even the most complex problems and has brought up amazing base technologies, transformed entire ecosystems and even explored Mars. When describing the specific characteristics of FOSS, a lot of emphasis is put on the swarm-based approach, in which a significant number of individuals work together in a collaborative approach to develop software. Yet, a lot of FOSS projects fuelling today’s infrastructure are maintained by few individuals. Many of those write code for fun, on voluntary basis, aside of their day job. Their main motivation is to solve a specific problem they are having. And they are fond of the principles of Open Source and Free Software. As those original creators expect others to benefit from their work as well, they are publicly sharing it under a FOSS license.

Dependency on voluntary software development as challenge

The downside of such “hobbyist” software developers is that – although they might be well qualified – their ability to assign continuous and sufficient time and priority to the project is limited.

In the worst case, due to a change in priorities and/or interest, their engagement within the project might decrease or even cease completely. For the project and its surrounding community this might be an unfortunate loss. For any company like ZEISS, who is relying on the project, this is a risk with potential impact on our daily workflows and/or product line(s).

ZEISS supports community engagement of their employees

With the goal to be an active and sustaining member within the global FOSS community, we have defined a company-wide policy on FOSS engagement. With focus on feasibility, it enables and appreciates the contribution to FOSS by any software engineer at ZEISS. The overall purpose is to facilitate community-based software development by active involvement, contributing our manifold engineering expertise and releasing unique work that could be relevant to more than us.

This also helps in relieving the previously mentioned challenge. If the actual project maintainers are short on time, a ZEISS engineer could be the one to add upon whilst preparing the FOSS component at question for its proper use in one of our products. All FOSS projects published by ZEISS can be found on GitHub: https://github.com/zeiss

Funding our employees’ favourite FOSS projects

To complement this, ZEISS has started in 2022 an initiative to fund projects that are particularly relevant to us. With that, project maintainers are supported to continue their valuable work and use the provided money to allocate more time on their important projects. ZEISS Employees across all business units voted for their favourite project(s) in three categories: productivity tool, software library, and FOSS foundation. In the second FOSS Funding round that was concluded this summer, six winners were determined to receive grants totaling 15,000 EUR:

  • Keepass, a light-weight and easy-to-use password manager;
  • VLC, a cross-platform multimedia player that supports countless file formats;
  • pytest, a framework that facilitates writing readable functional tests for software applications;
  • Inkscape, a powerful vector graphics editor;
  • FFmpeg, a multimedia framework for decoding, encoding, streaming and more; and
  • Python Software Foundation, an organization devoted to advancing open source technology related to the Python programming language.

Congratulations to all winner on your awesome projects, which are highly appreciated at ZEISS! Thanks a lot for your precious work and publicly sharing it!

Joining Linux Foundation and Zephyr Project

To further strengthen our ties in collaborative software development, we are happy to announce that the ZEISS group has recently become a proud member of the Linux Foundation and Zephyr Project.

The Linux Foundation is not only home to Linux and its surrounding ecosystem, but also maintains a wide range of initiatives that add value far beyond pure code development. To give a few examples: SPDX as the common standard to represent software composition in form of software bill of materials (SBOM) or the TODO Group as best practice exchange to succeed with Open Source governance in the enterprise.

The Zepyhr Project nurtures a modern and innovative real-time operating system, that may see more than one appearance in ZEISS’s future product lines.

Exciting times ahead, so stay tuned for our next round of FOSS funding or even better join our team ZEISS to forge FOSS on the mission to bring our innovative product portfolio to the next level!

Distributed Work – An Experience Report on the Practical Application of Remote Mob-Testing

Within ZEISS Digital Innovation (ZDI) there is an internal training event at regular intervals – the so-called ZDI Campus Event. As employees, we present software development topics by means of lectures, workshops or discussion rounds. 

Katharina had already reported on collaborative testing methods at the last ZDI Campus, and also published blog articles about Remote Pair Testing and Remote Mob Testing. Therefore, we wanted to continue the topic at the next ZDI Campus and offer a workshop on the topic of collaborative testing methods. However, due to the Covid-19 pandemic, the next campus had to be held online. Nevertheless, we wanted to offer several participants the opportunity to apply a test method using a practical example, and therefore decided to hold a remote Mob-Testing Workshop.  

But there was a challenge: We had never worked with so many people in the mob remotely! 

Structure of the workshop 

As described in the blog post about Remote Mob Testing, it makes more sense to supervise small groups of four to six people. Distributed work may otherwise lead to more frequent delays due to technical problems (e. g. poor connection, poor sound quality), which could reduce the time required for the current navigator. As a facilitator, you can also keep an overview of smaller groups and the participants can take on the role of navigator or driver more often.
(Zur Erläuterung der verschiedenen Rollen siehe ebenfalls Blogbeitrag Remote Mob Testing

Our setting looked like this:

  • Microsoft Teams as a communication platform  
  • Easy to understand test object (website)
  • 3 Facilitators  
  • 39 participants from the fields of QA, Development and Business Analysis 
  • Timeframe: 1.5 hours  

Because we wanted to give everyone the opportunity to get to know the Mob-Testing themselves by means of a practical example, we did not set a limit on participants in the run-up to the workshop. In the end, all three facilitators had more than 12 participants.  

person in front of a screen having a video conference
In remote mob testing, all participants take on the active role of the navigator once.

As a test object, we chose a simple website so that everyone could concentrate on communicating or getting to know the test method and not have to acquire additional knowledge about the application. 

Feedback 

Already during the course of the workshop, we noticed that waiting times for an active role (Driver or Navigator) could be perceived as unpleasant.   

This was also mentioned in the feedback round. Therefore, we recommend that the mob assists with test ideas, because it doesn’t mean that you can sit back and wander with your thoughts as a mob member. This also avoids double testing or having to admit that you were not paying attention.  

In some cases, it was difficult for some participants to focus purely on the role of the driver – executing the instructions of the navigator, and holding back on their own test ideas. However, the participants got used to it after some remarks by the facilitator. This aspect of Mob-Testing was considered to be very positive, because everyone in the role of the navigator can speak and contribute their own test ideas.  

However, the question arose as to why the roles Navigator and Driver could not be combined. The following can be said: It promotes the learning process when a member articulates step-by-step what he or she intends to do. In this way, more participants are involved in this active role. Communicating the destination makes it easier for the participants to follow the ideas of the navigator. Otherwise, some steps may be carried out too quickly, and with too little explanation. This would lose traceability and make it difficult for the mob to get actively involved.  

There was other positive feedback on the division of roles and the whole process. According to the respondents, the test approaches are partly obtained by the path taken by the previous navigator, and therefore viewed the test object from a variety of angles. For this reason, it is always useful to invite participants with different skills, depending on the purpose of the Mob-Testing session. This increases the learning process, and the number of test cases. The simple sample test object also helped to focus on the method and to internalize it. 

The collaborative work in Mob-Testing was highlighted very positively. This is how the agile thought is experienced.  

Solution approach for a large number of participants 

The problem of too many participants could be solved by limiting the size of the group in advance or by introducing a new role: the role of spectator. A separation would then be made between active participants on the one hand and spectators on the other. Participants would follow the procedure described above, and follow the roles distribution (navigator, driver, mob) and the role change. The spectators would only observe and not participate. Comments by them would not be allowed either, because this could disturb the active participants with a large number of spectators. 

Conclusion 

All in all, the workshop was very well received at the Campus event, and showed that it is very possible to use Mob-Testing remotely, and therefore for distributed work. This means that cooperation can be maintained, even if it is not always possible to meet on site.  

This post was written by:

Maria Petzold

Maria Petzold has been working at ZEISS Digital Innovation since 2010. As a test manager, her focus is on software quality assurance. She was able to gain her test experience especially in medical software projects.

See author’s posts

UI-Dev-Session (Part 1) – Efficiently Solve UI Errors in the Team

The central objective of each style guide is to ensure a consistent appearance and a consistent user experience (UX) across multiple applications. For this reason, there are detailed specifications for applications of the ZEISS Group as to how a user interface (UI) should look and behave. Any application that is to be published and used commercially must comply with these requirements. 

Figure 1 illustrates the complexity and the manifold states that hide behind even very simple UI elements. The efforts for the correct implementation of such states are usually hidden and are often overlooked during application development or given lower priority compared to the implementation of functions.

Graphic showing the different states of a button in the ZEISS style guide
Figure 1: Different states of a button in the ZEISS style guide

With an advanced project duration, small deviations from the style guide accumulate, which quickly deceive the overall picture. Other classic examples of such UI errors are: 

  • Missing states of UI elements (Hover, Focused, …) 
  • Incorrect use of font sizes, fonts and font colors 
  • Incorrect use of greyscales for surfaces, borders or dividing lines 
  • Incorrect spacing and positioning of UI elements 

Although such deviations can usually be corrected quickly, extensive creation and acceptance processes often result in disproportionate effort for such comparatively small adjustments. If there are also misunderstandings or misinterpretations of the design specifications and several feedback loops are required, this is a negative experience for all involved. 

In order to correct such small UI errors more effectively and efficiently and thus improve the product piece by piece and adapt it to the style guide, we have created and established an uncomplicated form of collaboration.

Pair Programming with Specialists for UI/UX   

Pair programming has been successfully used within the development team of our project for a long time. It promotes collaboration and the quality of the code through the four-eyes principle. Two people from the development team work simultaneously and directly on the program code. Through discussion, criticism and the introduction of new ideas, high-quality code should be generated and development time saved.  

We made use of this principle in the project and expanded the circle of participants to include specialists for UI/UX in order to be able to give developers direct feedback on their adaptations to the user interface. The requirements and requests for changes to the user interface are communicated by the experts for UI/UX directly in the appointment and the changes are checked instead of documenting them in the backlog and waiting for them to be implemented correctly at some point. The people who specialize in UI/UX include those responsible for the user interface specifications, who are significantly involved in the development of the Figma UI design.  

The regular exchange in this circle is called UI Dev session or simply Dev session. The whole thing works very well in a decentralized way in mobile work, because thanks to Microsoft Teams and its screen-sharing function, all participants can see the changes to the code and the user interface at the same time.  

To create a framework for pair programming, we have created the following “rules of the game”: 

  1. People from the field of development as well as from the field of UI/UX participate. The group consists of two to a maximum of four people. Together, we search for the solution for specific UI errors and program live on the code. 
  1. A UI Dev session does not have a predefined scope. On the contrary, the objectives achieved are limited by the time available. 
  1. Depending on the requirements of the project, a UI Dev session should take place at regular intervals and should have a clear time frame. For example, 2-3 hours per sprint, week or month can be reserved for a UI Dev session. This means that the time required to solve UI errors should be proportionate and consistent. 
  1. Possible topics are maintained in a list by the specialists for UI/UX and processed iteratively in several UI Dev sessions. The basis for this is, for example, deviations between implementation and style guide or feedback from usability tests. 
  1. The development team is free to select topics from the list and prepare them in advance if need be. This should help to solve as many issues as possible in a short time. However, where necessary, priority may be given to issues for maximum benefit, in order to solve the most important issues first, especially in tight time frames. 
  1. The activities on unexpectedly complex topics whose live implementation is beyond the time frame of a UI Dev session will be stopped after the participants agree and outsourced to other backlog items (e. g. user stories or spikes) and edited later. 

The edited and solved UI errors should be documented after the UI Dev session and made available to the project team. This allows each project member to see what changes have been made in which UI Dev session. In addition, it is a good idea to present the topics covered in the Sprint Review briefly to the entire project team.  

Example of deviations from implementation (left) and style guide-compliant Figma design (right)
Abbildung 2: Beispiel für Abweichungen von der Implementierung (links)
und für Styleguide-konformes Figma-Design (rechts)

Conclusion

Whether clear deviations from the style guide, optimizations after usability tests or other minor adjustments to the user interface: The procedure described in this article for conducting a joint UI Dev session with developers and UI/UX specialists promotes team collaboration and can solve UI errors quickly and efficiently. The documentation effort should be reduced to a minimum and the time required for implementation should be clearly defined. Through iterative implementation of the UI dev sessions, the list of UI errors is processed piecemeal, whereby the project team raises a mutual awareness of such issues. 

The UI-Dev Session is now a proven tool in our project and an integral part of every sprint. My colleague Franziska Kubitz will describe a detailed experience of our project in the second part of this blog article series

Christmas party in times of Corona: The 2nd ZEISS Digital Innovation Online Campus Event

As early as spring we at ZEISS Digital Innovation (ZDI) started to plan our Christmas party which normally takes place on the Friday before the 1st Sunday of Advent. In 2020 we quickly came to realize that a traditional Christmas party where all the employees normally meet in Dresden and celebrate together would unfortunately not be possible this time. Cancelling the Christmas party was not an option for us either, so we started to search for a new format.

We came back to the idea of our 1st ZDI online campus event which had already received a lot of positive feedback. It was especially important to us this time that we created an all-encompassing festive mood, in addition to the intern knowledge sharing. But how could we bring this home to our colleagues?

A map showing all the locations from which our employees were connected.
Figure 1: Our colleagues participated in the online campus event from a wide variety of locations.

A small Christmas surprise for all employees

To enhance a Christmas atmosphere all employees received a small Christmas parcel by mail with the request that it should only be opened on the day of our common online campus event.

All 345 parcels were personally packed by the organizational team to a background of festive Christmas music. We were happy that the Christmas surprise arrived in time at the homes of all our colleagues in Germany and Hungary.

So all were on time for our 2nd ZDI online campus event with Christmas goodies, mulled wine and traditional Christmas spices to create a delicious punch, an Advent calendar, a Christmas party hat and other small gifts and off we go!

2nd online campus event including online team game and Christmas celebration

Using the positive experiences from our 1st ZDI online campus event this time again we offered different lecture slots from and for our colleagues during the whole day. The technical realization was done again via Microsoft Teams. We had 29 lectures altogether covering a variety of different topics such as Java, .NET, Cloud, Usability, Agile and Web. Through lessons learned the first time around we adapted the length of the lecture slots increasing them to 45 minutes instead of 30 with 15-minute breaks in between to change. So everyone had time to breathe and mentally prepare for the next one.

Timetable of all presentations at our 2nd ZEISS Digital Innovation online campus event.
Figure 2: A total of 29 presentations in 6 parallel slots were given on related topics.

After a longer lunch break our online team game took place, 28 teams took part, consisting of nine to ten players in each one. When we put together the teams we paid great attention to the make-up of each team ensuring that they were as heterogeneous as possible regarding the level of maturity, location and business area. Each group had their own team room for solving the tasks, it was a super way to get to know each other. The activities included among other things general knowledge questions, charades and quizzes as well as practicing the Christmas team contribution, which every team presented live at the end of our online campus event within the framework of our collective Christmas party.

We kicked off our Christmas Celebration together by drinking a toast! After that each team started to show their live Christmas contributions. There were musical and poetic presentations and performances including Christmas greetings in different languages together with Christmas film tips and recommendations. All teams were extremely creative and the team chat was also available and used actively adding another dimension to our party. So despite the wide distribution and accompanying physical distance, there was nevertheless a contemplative Christmas mood that was felt by all.  

Conclusion

We all knew that an online format and a virtual Christmas celebration could never replace the feeling of a real on-site Christmas party with ice skating, delicious food, dancing and the relaxed atmosphere amongst one other. Still, we were pleasantly surprised how much festive, community spirit could nonetheless be felt online. It has shown us once more that we are a strong team acting in unison and despite Corona we are ready to make the best of the current situation breaking new ground together.

It is uncertain if we may celebrate a summer or Christmas party with all the colleagues in Dresden on-site this year. But one thing is already for sure: our new online campus event format with team games is certain to outlast Corona.

A Project Goes Agile: Challenges and Solutions

The term “agile” has become unavoidable in the software industry these days. This was certainly the reason why it was decided to restructure the entire process in my current client project. The most important aspect: It was to become agile, the objective being an improvement on every level.

Switching to a new process in a project that has been in progress for years—and has kind of worked—was and is, in fact, not the easiest task a team can take on. That was something that not only the product owner (PO) and the decision-makers, but the developers and testers in particular had to learn. While the transition was underway, we, the testers, noticed several issues that needed to be changed. I would like to discuss these issues here because they may be helpful for other teams in similar situations.

For our team, these challenges meant a lot of work, but overcoming them in the end gave us an important sense of achievement.

New refinement process and missing acceptance criteria

The entire workflow, from the definition of requirements to the development and the testing of the application, was redefined from the ground up, introducing a new refinement process that was intended to ensure better task processing by means of a defined JIRA ticket structure.

Unfortunately, the team of developers and testers was not involved in the definition of this standardized content. As a result, there were no acceptance criteria for the first cycles with the new process. The tickets did not give any definition against which we could have tested.

Suggestion for improvement

During our weekly tester standup, we addressed the fact that this method did not allow the testers to work effectively. We also pointed out that it would be useful to involve the respective staff in the project in order to define the content for the refinement. We suggested that both the technical department and the developers and testers draft their requirements for a good ticket, and to develop a Definition of Ready (DOR) guideline on this basis.
This suggestion was quickly implemented and applied. The acceptance criteria for the test are now an integral part of the tickets, allowing for testing to be done without questions in this respect.

Involving the team and living the agile method

Another problem that correlated with the first issue was the lack of dialogue with the team members. At first, the transition to the agile method was simply dictated “from on high”. This is in itself opposed to the agile method, which is supposed to focus on the people involved. In addition, an arbitrary method was forced upon the ongoing project and the project staff. Naturally, this was met with resistance. The staff not only felt ignored—they were being forced into a process template that was not tailored for the project and did not suit the staff. The general mood in the project was tense, and the work became less efficient.

The tester is the last stop in the development process of the software before it is delivered to the client. We have to put ourselves in the technical department’s position and empathize with their concerns; coordinate with the developers, the PO and other departments; and always focus on quality as the first priority. Furthermore, every error in the upstream process multiplies before it reaches the tester. This gives us a decisive advantage: We get an overview of the entire process because we see a part of every section. Consequently, it is easier for us to reflect on possible weaknesses.

Figure 1: Cross-departmental discussions on the successful introduction of an agile process

Suggestion for improvement

We used this advantage and told the PO that the staff must imperatively be involved when an agile process is introduced. After all, it is the staff that has to support and live the new process. Furthermore, it is important not to consider a certain method and adopt it for the project without any adjustment. Based on our many years of project experience, we could tell them that the method has to suit the project and the staff in order to be effective. For this purpose, it is important to not only consider one method, but to combine several methods, and to test and adjust them bit by bit, step by step.

This suggestion was heeded as well, and several meetings were scheduled to clear up any incongruities and eliminate weaknesses. Items on the to-do list were defined, and a dialogue was started. The mood in the project improved significantly, and the work is now going much more smoothly again.

Stepchild automation

In the course of the process transition, the issue of automation should be addressed more seriously as well. From the tester to the decision-makers, everybody agreed that this issue was important and urgent. However, due to the numerous difficulties encountered during the introduction of the new process, this issue was dropped from the agenda.

Suggestion for improvement

First of all, the testing department broached the subject again and again, gathered information, and recommended tools and tested them for their suitability. They also actively sought to liaise with key persons associated with this topic. This required a certain intuition to watch for just the right moment in some instances. All the information was reported to the PO, and we inquired about the progress of this measure at regular intervals.

These points were taken up as well, and the issue was pushed up towards the top of the agenda. The PO called meetings with the decision-makers and will continue to advocate for progress in the field of automation. The choice of a tool, the integration into the process and the question of an increase in staff have not been decided yet.

Conclusion

In conclusion, my experience that the transition of existing processes to another method can only be successful with psychological skill, a focus on the key points and dialogue with the team members has been confirmed. One thing such a transition always needs is time. It is important to push a process, but it is just as important to wait for the right moment in order to use the full potential and seize opportunities at the right time.

As a tester in this client project, I saw that it is advisable to have some people who have already worked with the agile method involved on every level of the project for such a reorganization. This way, their experience can be taken into account and contributes significantly to successful implementation. Assistance from third parties can be called in as well, if necessary. In hindsight, this client project benefited from the fact that both ZEISS Digital Innovation GmbH and I myself had already had experience with agile methods.

Sales Without Coffee—Impossible!?

When you switch to the sales department, you quickly realize: Your consumption of coffee is going to increase. Because if the client asks you whether you would like some coffee—would you want to start off a personal meeting with a “No”?

Coffee is usually part of the small talk that creates a positive basis for the first encounter at the beginning of most sales meetings. As you talk about coffee—the type, the method of preparation, etc.—and walk towards the coffee table, you get to know each other and start building a relationship. This is a basis that you learn to appreciate.

Tasse Kaffee und Brille im Büro-Arbeitsumfeld

Or it was, until Coronavirus! Not only did the cancellation of flights make reaching the clients more difficult, but the whole situation also left us at a loss at first: How were we supposed to identify new issues with existing or new clients? How were we supposed to convince the client to choose us, in light of smaller budgets and reprioritization, without being on site? How were we supposed to build the necessary trust without ever having sat down together?

For the service sector in particular, these obstacles seemed to be insurmountable at first—but fortunately, that changed quickly. Just like the other divisions of ZEISS Digital Innovation, here i sales and in the field of positioning, we examined the tools used by our development teams, who have been practicing distributed software development for years. And we used them for inspiration.

The comparison of all the sales colleagues held every two weeks has always been done on a distributed basis and supported by our CRM (SalesForce) anyway. In addition, our new customer sales department and the marketing team also switched to a daily mode. For example, we shortened our sales sprint from four months to four weeks, i.e. the marketing team synchronizes with new customer sales along the campaigns every morning at 9:30 a.m., and they discuss events, items on their to-do lists, and challenges. Every four weeks, we do a retrospective, a review and planning, concluding and reflecting upon the past four weeks and planning the following weeks. The new four-week cycle was necessary because at the end of March 2020, nobody was able to foresee which issues would need to be prioritized in June, but that would have been a necessary prerequisite to continue the four-month cycle we used before the pandemic.

In order to be able to do the new, distributed dailies from home too, we used Skype for Business and Microsoft Planner at first. Later, we switched to MS Teams, using the associated MS Whiteboard for content-related work as required. 

Now we have a tool set that has also proven to be very beneficial in the interaction with our clients over the past weeks. MS Teams has become customary in virtually every organization, and everybody is much more willing to use conferencing tools, allowing us to take this path quickly and straightforwardly. An aspect that we find to be particularly favorable is the willingness to turn on the video stream in a meeting instead of only using audio. You could say that the video stream between the parties involved is a substitute for having coffee together: it gives both parties a better sense of each other and reduces issues of interpretation that often occur in phone conferences. With new clients or new contacts in particular, this is a true blessing for any future collaboration.

We also needed to adapt our rituals in the preliminary project stages. For example, we could no longer do a two-day project vision workshop with the client on site. Alternatively, we now do 4 x 0.5 days, each with 2 x 2 h sessions in MS Teams, immediately documented by means of a Microsoft Whiteboard, where they are visible for and editable by everyone. This way, we have been able to start several projects during the Corona crisis—even with new clients who have never worked with us before.  

This is an entirely new scenario that is still somewhat surreal and strange for us here in sales, and that will likely permanently change the sales process. In the end, we are having coffee together again—everyone in their own workspace, connected by MS Teams, Skype and the like.

Agile Business Management at ZEISS Digital Innovation

Making Business Thrive Through Collaboration, Transparency and Employee Participation! For us, becoming a more agile company which is again successful over the long term started with changes in the company management.

Why did we need to change and set out in a new direction?

Ever since the incorporation of Saxonia Systems AG, which became ZEISS Digital Innovation in March 2020, the company had been growing continuously. But in 2008 and 2009, the crisis in the semiconductor industry and the nearly simultaneous financial crisis caused a severe drop in revenues. At the time, Saxonia Systems generated a large part of its revenues in the semiconductor industry, which is why the company’s crisis reached its peak in the middle of 2010. The main reasons for the dire situation were the unsatisfactory cooperation within the management due to the “kingdoms” that had emerged in the past, the lack of strategy and goals, and a lack of focus in the product portfolio.

Figure 1: Challenges faced by our company

Where did we start the change?

The company’s management was convinced that a new form of cooperation and leadership was required—at every level, but starting with the management. From that point on, the management was supposed to work as a team, in keeping with the motto “United we are strong and can do anything.” The strategy team established at that time was well aware that the challenges outlined above could not be overcome on an operative level. In the past, each manager was trapped in their own operative rut. To enable them to leave it, we had to start on the next level up, i.e. with the strategic business management. If change is initiated there, that has a positive effect on all other management disciplines such as self-management, employee management, and operative business management. A strategy that is based on the employees’ contribution changes all the management areas. This is the only way to develop and agree on a vision and corporate objectives together. The management put this knowledge into practice, and to this day, the strategy team meets for a two-day strategy meeting three times per year. At this meeting, they address the current issues that are most important for the company.

Figure 2: Levers of change in strategic business management

However, a strategy team alone did not do the trick: the form of cooperation needed to be improved as well. The strategy team had to consider how everybody could become more disciplined and consistent as a team in the future, precisely to avoid developing strategies that only look good on paper. ZEISS Digital Innovation already had known and lived agility in its operative units in agile software development projects. Is the agile approach possible in management? The answer is perfectly clear: Yes!

In the end, the strategy team had no choice. To overcome the challenges they were facing, the management needed to cooperate much more closely and become more flexible, faster and, consequently, more agile. Therefore, the scrum method was adopted both in agile software development projects and in the management of the company. The result was the agile strategy process.

What has been the result of the continuous cooperation and improvement?

Over the course of the last 10 years, continuous optimization in the strategic work has resulted in a Best Practice Framework. It includes innovative and practicable concepts, methods, principles and tools that have enabled the company to overcome all the challenges it has faced so far. The Framework is meant to support the strategic work of ZEISS Digital Innovation in the future as well. The agile strategy process constitutes the basis for permanent transformation in our company, and the key element of the new form of cooperation across hierarchies, departments and locations.

The Framework that has evolved over time contains all the factors of success that allow for long-term corporate objectives to be achieved in a flexible manner:

  1. A corporate objective to be achieved and a strategy for achieving it
  2. Leadership and cooperation aligned towards the corporate objective
  3. An iterative, consistent and disciplined course of action to implement the prioritized strategic initiatives
  4. Common values and principles
Figure 3: Our Best Practice Framework—evolving since 2010

It is important to ensure that these four points are transparent throughout the entire company, and to continuously work on them—this builds trust among the employees. Only when everybody knows where they are headed and what the framework of objectives is, is it possible to pool and focus everybody’s strengths, energies and independent entrepreneurial activities within the company. Transparency towards the objective in particular constitutes the basis for all the employees to contribute their thoughts and ideas and help pave the way towards it. Transparency helps to avoid the duplication of efforts, to share knowledge, and to provide input for employees’ creativity. This often gives rise to valuable new ideas for the continued development of the company.

The iterative, step-by-step approach and the opportunity to actively participate in the company’s development allows for the employees to continuously be included in the journey of change towards our corporate objective. This way, continuous change in the company becomes the norm. And this facilitates commitment, employee loyalty and independent action. Intrinsically motivated employees are capable of great things.

How have we changed since 2010?

Still, nobody on the strategy team or in middle management of what is now ZEISS Digital Innovation expected our ambitious goals to be achieved this quickly. Here are some results, facts and figures to underscore the exceptionally successful development.

2010

Today

IT service provider for everything
with a business model in consulting

Piktogramm: Handschlag

Specialist in customized software development
agile software development projects with well-coordinated teams at the company’s own locations


160 employees

Piktogramm: Hände halten sich aneinander fest

300 employees


Drop in revenue from EUR 17.3 to 12.9 million

EBIT -kEUR 500

Piktogramm: Geldbeutel

Revenue EUR 35 million

EBIT EUR 3.5 million
(results of 2019)


Almost no interdepartmental collaboration

Piktogramm: Puzzle-Teile

Intense interdepartmental strategic and operative collaboration


No common vision and strategy, lack of transparency

Piktogramm: Leiter führt in eine Wolke

Target, strategy, strategy process

365d of transparency about the where, why, how and what


General store, lack of focus and sustainability

Piktogramm: Pfeil steckt in der Mitte einer Zielscheibe

Total of 70 initiatives completed since 2010, 5 currently underway, award for portfolio attractiveness


Little ability to change

Piktogramm: Ziffernblatt mit Pfeilen, die im Kreis darum herumführen

Change is the norm


Information and communication with the workforce twice a year at an in-house conference and the Christmas party

Piktogramm: zwei Sprechblasen mit einem Fragezeichen in der einen und einem Ausrufezeichen in der anderen

Intense 14-day company-wide information and communication regarding strategy / ZDI standups for all employees


No involvement of employees in the company’s continued development

Piktogramm: 2 Personen, von denen eine die Hand hebt, sprechen vor Publikum

Any employee who wants to get involved in strategic initiatives can do so—employees help pave the way towards the vision


Culture of finger-pointing, monopolies, expanding power, inconsistency, tattling, gossiping, everybody going their own way, mistrust…

Piktogramm: eine Person steht mit verschränkten Armen im Vordergrund, hinter ihr stehen vier weitere Personen

Togetherness, openness, respect, appreciation, fun, emotions, independence, commitment, trust, dialogue, …


Saxonia Systems AG

Piktogramm: 2 Personen geben sich High Five, zwei weitere Personen stehen im Hintergrund

ZEISS Digital Innovation

Part of the ZEISS Group


Why has this course of action been so helpful?

The course of action that has evolved based on our positive and negative experiences helps us to keep up with, and even keep ahead of, the ever-changing world. We are able to adapt and organize ourselves in a flexible manner without losing sight of our objectives. We join forces and focus on the respective high-priority issues that are beneficial to our continuous development.

Making our business thrive through collaboration, transparency and employee participation!

Figure 4: Benefits of the Framework

Within the framework of the permanent transformation initiated at the end of 2010, the company has achieved much, but it will not stop at that. Important basic elements of success that will continue to play a role for us will be addressed in other posts in this series.

Collaboration in times of Corona – what we all can learn from agile software development

The current crisis, caused by COVID-19, is challenging the most companies worldwide for several weeks now. From one moment to the next nearly 95% of our colleagues moved in to their home office. Most of them are still working from home. How does that fact affect my work in the Sales and Marketing team?

While working in distributed teams and independent of the location is quite common (have a look at our last blog post: Software Development in Corona times – Business as usual?) it was a novelty for our central services (accounting, IT, HR, Marketing, …). As an internal service provider for the employees of ZEISS Digital Innovation the main focus of our work was to be a local contact  for our „customers” and react directly to their requests. Simultaneous to our organizational affiliation to Team ZEISS and the high workload that came along with the related brand change, the shift to home office confronted us with new challenges.

My workplace in the home office
Figure 1: My workplace in the home office

How did we manage this transition mainly trouble-free and while keeping up our high level of performance? By learning from agile methods!

For many years we are following the basic principles of agile procedures in our projects as well as in management and developed our own agile process based on Scrum. For our collaboration in the central services we implemented some of the values, artifacts, and methods as well. This is helping us in this difficult stage. In general, for our internal corporate communication and especially for the collaboration of my team, which now consits of five team members. At this occasion it is important to mention, that we are only orient ourselves towards these procedures and don’t apply them like they appear in textbooks.

With an iterative approach, including Planning, Review and Retrospective, we ensure that our campaigns remain innovative, that we focus on the right things even when there are many campaigns running in parallel, and steady questioning ourselves. Meetings for reflexion (similar to project retrospectives), where we deduce Lessons Learned, belong to our daily work as well as an open culture of communication, honest feedback and creative or brainstorming events. Creative work and an agile mindset require a certain readiness for flexibility, so wereorganized our collaboration methods and quickly acclimatised ourselves to the new situation.  

Team retro with improvised whiteboard
Figure 2: Team retro with improvised whiteboard

But what does that mean in practice? Which „tools“ helped us to organize our work efficiently even in the home office and while working distributed?

Dailys

Because we didn`t meet in our office every day and did not notice directly and across the desk on which topics the other team members are working on, we quickly noticed a higher need for coordination. After a short time we established a daily meeting as a reaction. Every morning the team members sync their daily tasks and report about the tasks they dealt with the last day. We defined a timebox of 20 minutes for ourselves. It is important, that everybody gets the chance to speak and also shortly tells if there are maybe challenges that could affect their work (like too many meetings, childcare and home schooling, …). To make sure that we all stay in the defined timebox we nominated a Scrum Master who moderates the meeting. She has to ensure, that maybe upcoming discussions are clarified later in separate ad-hoc meetings and not block the daily.

Iterative Planning in short terms

In consequence of Corona and the accompanying ever-changing general conditions (like cancelled events, changing communication channels, …) we switched from a three-monthly planning cycle to a four-week period. So we can customize our tasks continuous to the quick changing priorities. To make sure that we nevertheless do not forget several long-term tasks, we have a backlog were we store all the activities which we want to work on in a long term, but are not urgent or important at the moment.

This backlog is closely linked to the next topic.

Visualization with suitable tools and a good infrastructure

Technical conditions are essential for working together. A Sharepoint or OneDrive for data sharing, video conferencing via Skype or MS Teams, a Wiki with a clear documentation of the campaigns and a joint task board are worth a mint and only a small set of the tools we are working with. To keep an eye on our tasks, we use MS Teams and the integrated Microsoft Planner. There we collect and record (similar to a Kanban Board) all our tasks and thus are able to evaluate in our Planning and Review meetings what we managed in the last sprint and what we want to do in the next iteration. As an internal service centre we have a lot and steady upcoming requests from different stakeholders, so we use the board to document all requirements the to ensure that (especially in the case of an unexpected absence or in Substitution situations) not been forgotten. In general transparency is one of our top priorities, but however we focus on the (a bit customized) agile manifesto: working software campaigns over comprehensive documentation (https://agilemanifesto.org/iso/de/manifesto.html).

Fair enough when tools and processes are working. But what about the interpersonal communication? We strive to have an atmosphere in our communication which is basing on open communication and values like trust, commitment, openness and mutual respect. And in the middle of this communication there are always humans and a working team, that must rely on each other. This team spirit also rises by the short talks in the meantime, by spending a lunch break together or making some jokes in the coffee kitchen. All this is really hard to put in practice when „social distancing“ and home office is on the daily schedule. To prevent that we drift apart as a team, we implemented a weekly virtual coffee break. We use this event to talk with a cup of coffee (or something else) about off topics and what concerns us at the moment. Just the things we would normally talk about in our breaks and in the corridor – not about thing what we have to deal with in our daily business. And of course, with video, to see each other from time to time.

Weekly virtual coffee break in the team
Figure 3: Weekly virtual coffee break in the team

Also, beyond team level there are some established formats resulting from our agile management process, that help us – e.g. our ZEISS Stand-up (general company meeting). Normally in a six week regular circle, our management informs about all important topics, data and facts. Every employee who is interested in participation, has given the opportunity to follow the explanations in his working time via Skype or on-site and ask questions afterwards. As a important cornerstone of our company information and communication this is ensuring transparency und takes since the 20.03.2020 place every week, to inform about all the actual corporate development in the crisis and the measures we adopted because of that. Next to the economic situation there were also some special topics to talk about, like the hygiene concept or the „Corona parental benefit“ when employees with children have minus hours. Another small puzzle piece, that gives us security and trust and make the corporate collaboration easier in this crisis.  

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.

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.