agile Archives - Digital Innovation Blog

Can agile software development work in a regulated environment? A focus on medical devices and diagnostic industry.

Health Solutions

What are benefits, challenges, and critical success factors in implementation?

Business context

Studies have shown that digital transformation in the healthcare industry has accelerated tremendously over the past five years. One catalyzing aspect has been the COVID-19 pandemic, which has led to changes in the interactions between patients and healthcare professionals. As part of this process, new technologies have been developed that have enabled many tasks to be performed remotely. Medical device and life science companies must now respond in a timely manner to address these changing conditions. Meanwhile the rise of digital solutions also raised the customer expectations that they are enabled in their everyday work in the same way and in the same quality what they know from other industries in their everyday lives (e.g. for entertainment or for travel organization).

In these industries, R&D organizations have many times successfully used agile development methods to achieve this level of digitization. Medical device and life science companies, on the other hand, have to adhere to strict regulations and internal processes that limit agile efforts due to regulatory requirements. Can agile development frameworks be adapted to help address these challenges, thereby accelerating the software development process and making it flexible and user-centric through multiple iterations?

Managing software R&D projects using agile methodology in general can improve efficiency in several ways

Time-to-market: With agile methodology delivering working software happens in short sprints, which can help teams to focus on the core use cases of the product and get that to market faster.

Resource utilization: By estimating costs for each product increment and closely monitoring progress, teams can optimize resource utilization and reduce waste.

Continuous improvement: The agile methodology emphasizes continuous improvement and feedback. Teams are encouraged to improve their processes and be more efficient.

Reduced rework: By identifying issues or new requirements early in the project and fixing or implementing them quickly, teams can reduce the risk of costly rework and ensure that the project meets customer and user needs..

What are the challenges of introducing agile methodologies in a regulated environment?

Regulatory compliance: Medical device companies must comply with a variety of regulations and standards, such as MDR or FDA regulations. Any new methodology must therefore be compliant with regulations and ensure that all required process steps for certification, as well as associated documentation, are completed in time for a software solution to be successfully approved.

Risk management: Medical device companies must manage a variety of risks, such as patient safety, data privacy, and cybersecurity. Appropriate identification, management, and monitoring of these risks is critical to project success and must also be implemented in agile software development.

Documentation: Medical technology companies are required to keep detailed documentation on their software development processes and their results. The problem is that for software classified as a medical device, a complete technical file must be generated for approval for each new software release. This creates an additional documentation burden.

Stakeholder involvement: In healthcare, many stakeholders are involved in product and software development projects, including patients, physicians, regulators, and IT staff. It is important to ensure that the voices of all stakeholders are heard and their respective needs are considered.

How can the advantages of both approaches be combined?

1. Develop a detailed project plan

Working agile does not mean working without a plan. When using agile methods in a regulated environment, a detailed project plan should outline and document the project scope, objectives, schedule, resources required, and risks to be managed.

2. Create documents through automated processes

In a regulated environment, detailed documentation is required to demonstrate compliance with standards and regulations. Following the waterfall model, design input and output documents are created for a given project synchronization point detailing the risks, business requirements, architecture, testing, and operational aspects of the product being built. Agile methodologies can be adapted to include documentation requirements in the detailed product backlog elements.

The documents can be created before the start of a development sprint or a product increment to fulfil the regulatory requirements and to ensure the availability of the design inputs. However, they can describe a narrow scope that is relevant for the upcoming development period. Through automation in this area documentation creation, updates and approve cycles can be reduced significantly. Requirements, software designs and tests can be created close to the development environment that with the help of validated tools can later be transferred to comprehensive and consistent documents that are compliant with Quality Management System requirements.

3. Grow in test automation

There are several reasons why investing in test automation can make a project more efficient. When changes are made to software in a regulated environment, there is always the challenge of demonstrating that there is no negative impact on patient safety and overall effectiveness.

Or when a product moves from an implementation phase to a verification and validation phase, there are many necessary but time-consuming testing activities. In cross-functional agile teams, verification tasks for specific functions of the software solution may be part of the development sprints. The time to get feedback on the actual state of the product is significantly reduced with high levels of automation.

This also reduces the risk of introducing unintended side effects when making changes to an existing code. With proper test documentation and code quality, automated testing can formally cover business requirements and be used for verification activities, reducing the time required for a test cycle.

4. Manage risks continuously

Healthcare organizations must manage a variety of risks, such as patient safety, data privacy, and information security. Agile methodologies can be adapted to incorporate risk management practices such as risk identification, risk assessment, and risk mitigation in repeated shortened cycles, supported by the automated document creation process and automated testing against defined risk mitigations.

5. Engage stakeholder

Through regular sprint and product increment demonstration sessions, teams can show all key stakeholders the direction in which the digital solution is moving. As development cycles are shortened, patients, physicians, and IT staff can provide regular input to make change requests that the agile teams can follow. Customers, opinion leaders and partners should also be able to regularly express their opinions on how the solution should be designed. Medical technology companies can enable this, for example, through joint workshops or pilot phases based on intermediate product versions.

Conclusion

Implementing new processes, especially in a regulated environment, is fraught with additional difficulties and delays. However, integrating agile principles, supported by a team of industry experts and highly automated processes, enables an organization to quickly respond and react to new challenges arising from the changing demands of the medical device industry with a highly regulated environment.

➡️ Get in touch with us to exchange about your ideas and how we can help. And visit our website to learn more about us and our services.

➡️ See all other posts on our health solutions here.

A Project Goes Agile: Challenges and Solutions

Quality Assurance

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.

Agile Business Management at ZEISS Digital Innovation

Collaboration

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:

A corporate objective to be achieved and a strategy for achieving it
Leadership and cooperation aligned towards the corporate objective
An iterative, consistent and disciplined course of action to implement the prioritized strategic initiatives
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

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

Revenue EUR 35 million

EBIT EUR 3.5 million
(results of 2019)

Almost no interdepartmental collaboration

Intense interdepartmental strategic and operative collaboration

No common vision and strategy, lack of transparency

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!

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.

The QA Navigation Board workshop

Quality Assurance

The QA Navigation Board provides a visual aid to agile development teams which they can use to assess the planning aspects of quality assurance at an early stage. During the project duration, the QA Navigation Board can also be used as a reference for the current procedure and as a basis for potential improvements. » QA Navigation Board

The QA Navigation Board is developed within the framework of a workshop run by an agile QA coach. The duration of the workshop should not exceed 1.5 hours.

Preparation

All the parties involved in the agile project should be invited:

Development team (developers, testers)
Scrum master
Product owner
Other stakeholders and shareholders

The QA Navigation Board is affixed to a bulletin board or wall. In addition, each participant receives a printout of the QA Octant as a worksheet.

Step 1:

Presentation of the QA Navigation Board and the objectives of the workshop by the host (agile QA coach), and introduction of the participants.

Step 2:

Brief presentation of the QA Octant and the quality characteristics. The goal is for all the participants to be able to complete the worksheet and to understand the quality characteristics so that they do not talk at cross purposes later.

Furthermore, the participants agree on the dimensions of the QA Octant: Which label is to be given to the intervals of the diagram (1, 2, 3 or S, M, L, XL, etc.)? Then, the worksheets are handed out and completed within 5 to 10 minutes by each participant, the name of whom is indicated on the worksheet (cf. blog post: How to use the QA Octant).

Step 3:

At the end of this time, the host collects the worksheets and puts them up on a bulletin board or wall.

The host then goes through each of the quality characteristics. For this purpose, he identifies the common denominator (average) of each characteristic and discusses the greatest deviations with the respective persons (cf. planning poker). Once the team reaches a consensus regarding the value of a characteristic, the host documents this value.

Step 4:

Based on the valuation of the quality characteristics, the participants then deduce the necessary types of tests. The higher the value of a quality characteristic, the more likely it requires testing by means of an appropriate test procedure. The team then places the types of tests determined in the test pyramid of the QA Navigation Board.

Step 5:

Once all types of tests have been determined and placed, the necessary test resources and other test artifacts can be placed on the QA Navigation Board. A checklist can help in this respect (cf. blog post: The QA Map or “How to complete the QA Navigation Board”).

Step 6:

When the team has mostly completed the QA Navigation Board, it is put up in an appropriate place in the team room. The host concludes the workshop and points out that the QA Navigation Board can be updated and further developed by the team, and also used in retrospectives.

Download worksheet “QA Octant”

The QA Map or “How to complete the QA Navigation Board…”

Quality Assurance

The QA Navigation Board provides a visual aid to the development teams which they can use to assess the planning aspects of quality assurance at an early stage. During the project duration, the QA Navigation Board can also be used as a reference for the current procedure and as a basis for potential improvements. But how should the types of tests and other test artifacts be placed on the QA Navigation Board?

To answer the question, “How and where do we want to test?”, the team would have to comb through the entire development process to find and document test and QA aspects. The development process can be different for every project, which could quickly make this issue highly complex (Fig. 1).

Again, to facilitate the introduction of this topic to the teams, we have developed the QA Map. The QA Map gives the team a practical tool to plan and document the measures required for optimal testability of the projects. The objective is to determine all QA-relevant issues for the teams and development projects, using a playful approach and at an early stage.

QA map from the QA Navigation Board — *Figure 2: The QA Map*

After defining all the key test areas by means of the QA Octant and determining the necessary types of tests, all aspects of the test strategy, such as types of tests, resources and tools, can be visualized, discussed, and prioritized.

A good practice resulting from the workshops done in the past is using two tools to control the completion of the QA Map. The first is a competent host who leads the workshop in the right direction, and the second is using a check list. The check list comprises appropriate questions that are intended to provide suggestions in the workshop in order to complete the various parts of the QA Map. These questions are listed below and allocated to the respective field to be completed.

Requirements

What are the requirements?
Do the requirements support the preparation of the test case?
Can requirements and tests be linked?

Test / Code

Where do we place the tests?
Do we have the necessary skills?

Repository

Where do we store the test artifacts?
Are there different artifacts?

Test Management

How do we plan our tests?
How do we document our tests?
How do we report? And to whom?

Automation

How much test automation is required?
Do we need additional tools?
Do we need test data?

Build

How often do we want to build and test?
How do we want to integrate QA?
Do we want to test maintainability?

Test Environments

Do we have an adequate environment for every test?
Will we get in each other’s way?

*Figure 3: Example 1 of a completed QA Navigation Board*

*Figure 4: Example 2 of a completed QA Navigation Board*

Once all types of tests have been selected and the team has started to place the other test artifacts (e.g. tools, environments), the host can withdraw. The team should put up the final picture in the team room as an eye-catcher. This way, the QA Navigation Board plan can be used as a reference for the current procedure and as a basis for potential improvements.

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

Collaboration

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.

The User in the Center of Software Development

Usability

The focus of this blog article is the integration of User Cantered Design (UCD) into our software development process at Saxonia Systems AG (since 03/2020 ZEISS Digital Innovation). A highlight is put on the tools and methods used to tailor the software to the actual user’s needs.

The root of bad usability

Why doesn’t anyone use the new software? If this question arises, it is usually too late. The development is already completed, and the users stay away or continue to use the previous solution. If this happens it maybe has happened again, that the requirements collected do not align with the actual user’s requirements. This is a common real-world phenomenon, which shows itself in bad usability and low acceptance of the finished solution. One of the possible approaches is offered by User Centred Design (UCD). This puts the tasks, properties and goals of the future groups of users in the centre of the software development process to achieve a high usability of the final product.

User Centered Design at Saxonia Systems AG

Due to our agile software development process, reaction to changes and new requirements is fast. Early feedback from the future users is essential for high levels of usability. Our Scrum inspired agile process is extended with tools and methods of usability engineering so that the user is involved regularly from the beginning.

*Figure 1 UCD deliverables of our agile process*

At the start of the project the UCD elements are incorporated into the product vision. Beside classic parts like project goal or system scope, the description of prospective user groups and the usage context are sensible UCD additions.

The product backlog does not only contain user stories and technical spikes, but also contains room for design spikes, that enable the team to focus on usability issues. This can include prototypes as a basis for decisions or the planning and the carrying out of user studies.

Additional quality gates are added to the scrum artifacts Definition of Ready and Definition of Done, in order to guarantee, that the software fulfils future user requirements.

Before user stories are ready for implementation, they are supplemented with sketches, mock-ups or designs. These visualise the functions, that are to be implemented, to the team. If they can be applied, process models are also included to show more complex sequence of events.

User stories are considered done in the UCD perspective if the usability principles are met. This can be checked via an expert evaluation. Hereby the usability engineer checks the functions heuristically for the adherence to the rules. Additionally, the consistency of the application and the style-guide conformity are checked.

It is advisable to have a central storage for usability background knowledge, e.g. a team wiki.

That way a team can always get information on user feedback and current status regarding UCD. Recommended content is:

Information architecture
Domain model
System documentation
Studies and test results e.g. user studies and CUI tracking
Personas

As you can see in the preceding sections, we incorporate the prospective user into the development of custom software development. In our experience this is essential for a high usability and acceptance of the final product. By getting early feedback by the user and using agile and lightweight methods you can eliminate the starting question “Why doesn’t anyone use the software?”, from your vocabulary.

From sprint to sprint – my journey to becoming a Scrum Master

In my blog post I describe my path to becoming a Scrum Master and show, how exactly such a role change can look like. I will give you some tips to help you on your way and I hope it is also entertaining.

Many of us will know: A new project begins, new colleagues come up to you, new networks, tools, and so on. As a consultant you start getting to know your new environment. As a specialist I will do a good job, despite the new variables. It always gets interesting when I leave my specialist role behind and therefore leave my comfort zone. So how about slipping into a new task at this point? A role that can and should indirectly influence the project team?

First sprint: All beginnings are hard or what was that?

Initially restless nights were to be expected. Many questions and ideas all around the Scrum Master are in the air: Where do I begin with my work? What is the team thinking about it? What the hell am I exactly supposed to do?

There is something good about having so many thoughts in your head – apart from missing sleep. All the questions I have asked myself, I would like to have answered.

Tip 1: Clarify open questions as soon as possible to gain more and more security.

By now I can say, you do not have to answer all questions alone. Support will be given upon request.

Second sprint: The preparation phase

I was able to acquire the theoretical knowledge for my new task quite fast by using podcasts, blogs, and professional journals.

Theory is good and sets the foundation but without practical utilisation it is not worth much. Values like trust and empathy have a greater importance in this role. What you must be aware of is that you as a Scrum Master cannot really make a difference without the team. This is where I wanted to start and put my focus on. Maybe I could get into conversation with colleagues from the new project earlier.

Tip 2: It is no problem to openly admit that you have not yet completed x projects as a Scrum Master.
It possibly might incite the team to take the new paths together.

Third sprint: The start

My work begins with the introduction in the team. As described in sprint 2 I already did that. So first and foremost, it was about what I would contribute for the team. Words like organizer, moderator, supporter, and a few others fell. I was not very surprising. In sprint 1 and 2 those expressions were used a lot when it comes to the duties of a Scrum Master.

The next step was about applying all the information I have read and heard in my everyday working live. Here I definitely needed people with experience in this domain – contact persons that guided me throughout the first time. At this point my thanks again to my coach Ines. I was able to join first reviews and plannings followed by an evaluation and coaching. Slowly I got an idea of what I was heading for.

One of the first lectures I read in the beginning was “Was macht der Scrum Master den ganzen Tag“(German for “What does the Scrum Master do all day”) from Henning Wolf. Soon I could put this reading aside. It was much more than I thought.

Tip 3: Do not just ask yourself as Scrum Master the following question in the beginning, but in every iteration: “What did I contribute to make out team better?“

Fourth Sprint: Do It!

In my first days as a Scrum Master it was my task to create the foundation for improvements in the team. By closely working together with the Business Analysts (supporters of the product owner on the client side) and the team, we were able to identify open issues quickly. The end in which I was jumped was not as deep here. Step by step we optimised schedule chains, adapted processes, and worked out new ideas with the team, which should move us forward in our work. In addition to the organisational aspects, my first retrospective was also on the agenda. I think you can imagine that this was a pretty exciting date for me.

While the first attempts at the flipchart looked rather, well let us say, “modest”, it got better and better over time.

Tip 4: Visit a flipchart coaching if you have the opportunity – even just a few tricks can improve your presentation considerably.

Fifth sprint: Conclusion

I don’t find it hard to answer the question of Henning Wolf “Was macht der Scrum Master den ganzen Tag“(German for “What does the Scrum Master do all day”) mentioned before. It is a constant challenge for the Scrum Master and therefore for me to provide optimal support for the team and to continuously develop myself further. I was able to successfully complete my certification “CSM”, but this was certainly not the last milestone.

I am looking forward to all the things to come in my new role and of course to further Scrum Masters colleagues 😉 So if you are interested in supporting our team as a Scrum Master in the future, please contact our staff team at jobs.digitalinnovation@zeiss.com.

Couples Therapy – Successfully Integrating Service Providers

Collaboration

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.

The Independence of the Testers in an Agile Team

Quality Assurance

Whenever I talk about testing in agile teams, and I emphasize that the testers and developers work closely together, I am asked the same question: What about the independence of the testers?

Independence is a key aspect and ensures the quality of the product, especially in waterfall and V-model projects. The testers are unbiased auditors of both the requirements and the results of the development. They provide validation from the users’ perspective, and due to their separation from the developers, it is expected that their work is not influenced.

In an agile development team, all the parties involved in the development process work closely together. The team is interdisciplinary and consists of testers, developers and designers. Basically everyone that is required to implement the solution. And the team works hand-in-hand with the client and the product owner. Obviously, the independence required with traditional methods is not provided in an agile development team. But it is no longer necessary anyway.

I became aware of that again when I was in a planning meeting of a scrum team a few days ago, where the acceptance criteria for a story were being defined: It was about the deletion of an artifact, more specifically about the confirmation prompt before the deletion. Being an old hand in testing, I suggested to the team to include an acceptance criterion or a test idea for the case of the user clicking on Cancel, and the artifact not being deleted in this case. The response came promptly: “Why? That’s a matter of course, and shame on any developer who forgets it.” This answer did not come from a tester, but from a developer. The team agreed completely. And as promised, the test cases created included this case, and naturally, they all went green because the developers implemented it correctly.

The testers’ independence in the old world is making way for a “new” idea: Each and all of the parties involved in the project are responsible for the quality! In addition, the work of the product owner ensures that the client’s perspective is taken into account. The testers bring their trained testing skills to the team, and the developers share their programming know-how. Agile principles ensure that the testing instance—downstream of the development—is no longer necessary, and I specifically trust my scrum team to implement the other stories correctly as well.