Integration and Implementation of Scaled Agile Framework and V-Model in the Healthcare Sector Organization

Abstract

The development of medical technology devices leads to the introduction and use of agile methods, which enable the delivery of increasingly complex software with the fastest possible innovations. Delivery of the highest quality software must be considered during development, as medical products are important elements in saving human lives. Their development begins with determining a set of product requirements that exactly correspond to it. The development of specified medical products is finally delivered to the customer, who participates in the development. In this article, we present the use and combination of agile methods in software development, which correct and facilitate timely and continuous delivery of products. They also know how to smooth out a quick reaction to the customer’s changing needs and mainly focus on team management and communication. Specific agile methods make it possible to implement development through gradual improvements by integrating customer requirements towards the product. This article identifies three interconnected approaches to integrating agile methods and principles: SCRUM, SAFe, and Kanban combined with the V-model. The methods are gradually analysed based on the literature review, and the article presents a practical application in Siemens Healthcare Slovakia.

1. Introduction

Software development is a complex process of designing, creating, testing, and maintaining software applications. It contains several essential phases that differ depending on the specific project and methodology.

Software development methodologies define a framework, or rules and procedures followed throughout the Software Development Life Cycle (SDLC). These methodologies are designed to ensure efficiency and quality in software development. Currently, two primary software development methodologies exist—traditional and agile.

Some of the most well-known traditional methodologies are:

• Waterfall model—which clearly defines the phases of software development, while each phase must be completed before the next one begins,
• Prototyping—is based on the creation of a software prototype, its rapid creation and user testing,
• Incremental model—breaks down the development process into small manageable parts called increments, representing a portion of the complete system’s functionality,
• Spiral model—a risk-driven approach combining elements of iterative development and the waterfall model,
• V-model—defines testing as an integral part of the development process, where each development phase is connected to the corresponding testing phase.

Dissatisfaction with the traditional approach to software development in the 1990s led to the design of new methodologies called agile. The most well-known agile methodologies are Extreme Programming (XP), SCRUM, KANBAN, LEAN, and SAFe. The philosophy of agile development is contained in the Manifesto for Software Development [1]:

“We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work, we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan.

That is, while there is value in the items on

the right, we value the things on the left more.”

Choosing an appropriate methodology depends on the nature of the project, customer requirements, the team, and other factors. Development teams often combine aspects of different methodologies within a single project to achieve the best results.

One of the crucial aspects of software development, especially when it is focused on the healthcare sector, is software quality. Software quality in software development is defined as the extent to which software meets specified requirements, expectations, and standards. The most important standards that provide frameworks for evaluating and assuring the quality of software development are:

• ISO 9001—which provides a framework for improving the quality of processes and products in organizations [2],
• ISO/IEC 25010—which defines the software quality model and software quality assessment criteria [3],
• ISO/IEC 12207—which provides process models for the software life cycle [4],
• IEEE 1061—which provides guidelines for software evaluation and defines processes and criteria for quality evaluation [5].

The Validation and Verification (V&V) processes are the most essential software quality processes. Verification focuses on verifying whether the software has been developed following defined requirements, specifications, or standards. Verification aims to ensure that the development team has created software that precisely implements the required functions and specifications. Validation focuses on verifying whether the software meets the requirements and expectations of customers as end users. Testing is an essential process for V&V, with acceptance testing primarily associated with validation and unit testing with verification, although both involve integration and system testing.

These processes are defined with the standard ISO/IEC 25010, 12207, 90003, and IEEE 1012 for Systems and software engineering. It provides guidelines and procedures for their implementation in different contexts and industries [3,4,6,7].

As mentioned, development teams often combine different methodologies to achieve better results. A current trend is the integration of classical and agile approaches. The V-model is one of the classical software development methodologies focused on quality, especially in validation and verification. One of the latest agile methodologies is the SAFe framework. In this article, we will introduce their integration into HealthCare software development.

2. Theoretical Background

From our point of view, we wanted to present an article that is a real application in organizations focused on developing and producing medical software. We were interested in two research questions that we encountered:

RQ1. 

Are articles published with real applications of medical technology development using a combination of agile methods?

RQ2. 

What results did the combination of Agile methods, V-model, Kanban, and SAFe bring for the organization?

2.1. V-Model

The V-model is essentially an extension of the waterfall model, the first published software development model. The waterfall model was introduced by Winston W. Royce in 1970 in the article “Managing the Development of Large Software Systems” [8]. It was a linear and sequential model with phases: System Requirements, Software Requirements, Analysis, Program Design, Coding, Testing, and Operations. In the V-model, instead of moving linearly downward in the coding phase, the process bends upwards in the shape of the letter V (Figure 1). The left side of the letter represents requirements and creates the system specification, and the right side represents integration and validation. Each phase in the V-model has two goals: validation and verification. The goal of validation is the analysis of requirements. The verification aims to evaluate the requirements related to the validation in each phase. Therefore, the V-model is also known as the Verification and Validation model [9,10,11,12,13,14].

The V-model appeared earlier, although no public citations are available. The cited citations support that the V-model arose independently from multiple sources.

In 1979, Barry W. Boehm published a paper built on Vee. He used Vee in software engineering to emphasize the importance of verification and validation. Boehm distinguished between an upper part of the Vee for validation and a lower part for verification and linked these processes to the related requirements and specifications, respectively [15,16,17].

Figure 1. V-model [18,19,20].

Figure 1. V-model [18,19,20].

In 1992, Germany published a standard for governmental software projects. The standard originated from the Ministry of Defense and was established in the very early 1990s or even earlier. This comprehensive standard is a process description designated as “V-Modell^®”. This is an abbreviation for the German “Vorgehensmodell”, which could be translated as “process model.” It was made available to the public by Bröhl and Dröschel in 1993 [17]. A further developed edition in 1997 included system aspects referencing the ISO 12207 system definition [16]. Figure 1 shows the original V-model, where the advantage is that all testing activities are planned at the beginning of the product life cycle [18,19,20].

Verification and validation are equivalent to decomposition and recomposition, where the former technically divides the program requirements into smaller editable pieces of code, and the latter assembles them into a final product. Waterfall arrows represent planning actions.

Validation begins with the requirements design phase to define user needs. The acceptance test is designed to verify these requirements later. The next phase deals with system design; the task is to define the system architecture to create a platform, system, product, or process solution. A system testing plan will also be created to verify how the individual modules work together as a system. The third phase refers to the architecture design and aims to identify the list of modules and their specifications to support the system. In this phase, the integration test is designed. The fourth phase performs module design to define the programming functions of each module. In this phase, the unit test design is developed. The coding phase is located at the bottom of the V model, where the module designs are programmed according to the specifications.

Iteratively, when problems are encountered during the testing phase, the model is returned to the corresponding validation phase for corrective action. The V-model is suitable for both large and small projects due to its simplicity and comprehensibility of requirements [18]. However, in practical work, requirements often change, which leads to the repeated implementation of V-model individual steps [21].

In the verification phases, criteria in software engineering are often misunderstood. This is because the current V-model does not consider the process of gathering and reconciling user or customer requirements. The result is poor customer satisfaction and poorly set system quality, which causes a problem in the development process. Therefore, the authors refer to integrating the V-model and modern quality tools, where the Voice of the Customer is considered [18]. In practice, this should mean that software has become part of functionality and innovation in various areas, from telecommunications and medical devices to automotive systems [22,23].

The main advantage of combining the V-model with other agile methods is to reduce the project risk of delivering low-quality software implementations. Therefore, the combination leads to better project management, continuous customer coordination, and adaptation to changes through customer feedback [24,25].

2.2. SCRUM

Agile development refers to software and product development principles, values, and practices prioritizing flexibility, collaboration, and customer satisfaction. The Agile methodology emphasizes iterative and incremental progress, a self-organizing team that delivers small, functional project pieces in short time frames known as iterations or sprints. Fundamental principles and characteristics of Agile development include iterative and incremental development, customer involvement, cross-functional teams, flexibility and adaptability, continuous delivery, and emphasis on individuals and interactions [1,26].

Originating in the early 1990s, SCRUM is an agile project management framework created by Ken Schwaber and Jeff Sutherland [26]. Derived from the rugby term “scrummage” or “scrum”, it reflects a group of attacking players pushing together to gain control of the ball—an apt analogy for an efficient team with a clear goal. It is a method for restarting play. This word represents an efficient team with a clear goal. SCRUM outlines roles, artifacts, and ceremonies to guide the development process.

SCRUM defines the following roles [26]:

• Product Owner—is responsible for representing stakeholders’ interests, setting project goals, and maintaining the product backlog. Prioritizes backlog items and ensures that the team first works on the most valuable features. The Product Owner primarily communicates with the development team and stakeholders to ensure everyone understands the product’s goal and vision clearly.
• SCRUM Master—ensures a productive work environment, champions agile values and principles, and ensures adherence to SCRUM processes, procedures, and methods. The SCRUM Master helps the team by removing obstacles by supporting and coaching the team. The SCRUM Master is responsible for the SCRUM process.
• Development Team—is a self-organizing and cross-functional group responsible for delivering the product incrementally. During each sprint, the team members collaborate to transform items from the product backlog into a potentially releasable product increment. They are responsible for all aspects of product development.

SCRUM defines three artifacts [26]:

• Product Backlog—a list of all items/works needed to be completed in the product. It is dynamic and responds to changes in requirements, priorities, and understanding of the product.
• Sprint Backlog—is a subset of the Product Backlog selected for a particular sprint. It represents the work the development team plans to complete during the sprint. It is created during Sprint Planning and is owned by the development team.
• Increment—is the sum of all completed items completed during the sprint. It must meet the definition of “done”. The increment is the primary measure of progress.

In SCRUM are prescribed following ceremonies [26]:

• Sprint—fixed time-bound iteration (usually a month or less) within SCRUM, during which a potentially shippable product increment is created.
• Sprint Planning—during this ceremony, the SCRUM team (including the Product Owner and the Development Team) plans the work to be performed during the upcoming sprint. The team selects items from the product backlog to be included in the sprint backlog and agrees on a sprint goal.
• Daily SCRUM—the daily stand-up, held daily (usually in the morning), is a short meeting (10 min) where members of the development team share updates on their progress since the last meeting, discuss obstacles, and what they will carry out the next day.
• Sprint Review—the SCRUM team, stakeholders, and customers meet to review the progress and adjust the product backlog if necessary.
• Sprint Retrospective—after reviewing, the SCRUM team holds a sprint retrospective to reflect on the sprint and identify areas for improvement.

2.3. Kanban

Kanban is a lean method developed by Taiichi Ohno for Toyota in the early 1940s as part of a just-in-time approach [27,28]. Over the years, this method has gained tremendous popularity. The effort to introduce it into other sectors has been most successful in software development. With its flow visualization Kanban board, Kanban has played a key role in dynamic, structured, and flexible management. In 2009, a method combining SCRUM, Lean, and Kanban—Scrumban—was created. Over time, this method has proven to be suitable for any repetitive process [29].

Basic practices in Kanban are defining and visualizing workflow, actively managing its items, and its improvement [27,28]. In software development, the primary practices are visualization of work and limitation of work in progress (called WIP). Kanban manages all work through the Kanban board. WIP limits provide feedback on typical flow issues [27,28]. Unlike Scrum, which limits WIP per iteration, Kanban limits WIP per workflow state.

The Kanban board is divided into columns that represent different phases/stages of the workflow. Often, the Kanban board includes these basic columns: “To Do”, “In Progress”, and “Done”. Each work task is represented by a card that moves from one column to another [27,28].

Introducing limits on WIP means that a new task is only started once the current work is completed [27,28]. Limiting and optimizing the work in progress is Kanban’s main success.

The Kanban workflow maximizes value delivery, minimizes lead times, and ensures smooth work processes [27,28]. Kanban implements feedback loops in all areas of the process (such as strategy alignment, operational coordination, risk management, flow, replenishment, customer deliveries, and service improvement). Kanban is oriented toward continuous improvement.

2.4. SAFe

The Scaled Agile Framework^® (SAFe^®) was created by Dean Leffingwell in 2011 to implement agile practices in large organizations. It is now the most popular scaled agile framework, constantly maintained and updated. It has become an integral part of many industries. This framework scales agile for large projects managed by multiple teams, integrating practices from agile software development, lean product development, and the DevOps [30]. It includes flexibility, iteration, and collaboration from agile software development (SCRUM, KANBAN), such as roles (SCRUM Master, Product Owner, Development Team) and ceremonies (planning, reviews, retrospectives).

SAFe 6.0^® is based on ten Lean/Agile principles [30]:

• Take an economic view.
• Apply systems thinking.
• Assume variability; preserve options.
• Build incrementally with fast, integrated learning cycles.
• Base milestones on objective evaluation of working systems.
• Make value flow without interruptions.
• Apply cadence and synchronize with cross/domain planning.
• Unlock the intrinsic motivation of knowledge workers.
• Decentralize decision/making.
• Organize around value.

The official SAFe version is 6.0, which brings various levels of scale (Figure 2) [30]:

• Essential SAFe—is a basic level of SAFe oriented towards small organizations that want to adopt a basic set of roles, events, and artifacts and do not require the full scope of SAFe.
• Large Solution SAFe—is oriented for complex projects requiring coordination across teams’ coordination (up to 10 teams), including additional roles, events, and artifacts, such as solution backlogs and architectural runways.
• Portfolio SAFe—is oriented towards aligning the organization’s strategy and investment decisions with its business goals.
• Full SAFe—is a solution that includes all artifacts, roles, and competencies.

Figure 2. The SAFe 6.0^® [30].

Figure 2. The SAFe 6.0^® [30].

SAFe^® defines roles associated with different levels. Roles at the team level are the same as in SCRUM—Agile team, Product Owner, and SCRUM Master. SAFe also defines ART roles (Agile Release Train), which include [30]:

• Product Management—defining and supporting products that meet customers’ needs.
• System Architect—a small cross-discipline team defining the overall system architecture, nonfunctional requirements, subsystems, design interfaces, and collaborations.
• Release Train Engineer—the main SCRUM Master, responsible for optimizing the flow of value.
• Business Owners—a small group of stakeholders responsible for fitness for use, governance, and return on investment for a developed solution.

The key roles at the solution level are [30]:

• Solution Manager—prioritizes capabilities and ensures their well-definition and understanding.
• Solution Architect—is responsible for ensuring that delivered solutions are fit for their purpose.
• Solution Train Engineer—responsible for facilitating and managing all agile release trains.

The roles at the portfolio level are [30]:

• Epic Owners—responsible for defining an epic, calculating its benefits, and ensuring easy implementation.
• Enterprise Architect—manages architectural initiatives for the portfolio.

SAFe^® is a flow-based system requiring systematic identification and resolution of any interruptions to flow [30]. Flow is defined as smooth work through the entire value stream with minimal hand-offs, delays, and rework. In the context of SAFe, the flow is evident when teams, trains, and portfolios can effectively and consistently deliver high-quality products/services.

3. Related Work

We can define the V-model as one of the most important models of the software development life cycle. The V-model describes the stages of the software product development process, including individual steps from project definition to software delivery [31]. The International Standard Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems, IEC 61508, discusses the term lifecycle in the context of both the safety and software lifecycle [32].

The V-model has been widely used in automotive development, in particular from state-of-the-art analysis, mainly in software development such as safety-critical systems [9,11,22,33,34,35,36], car rental applications [10], and driving range estimation software for electric vehicles [9,37], an automatic framework for the design of Gateway [38], and according to the proposed data-based V-Model, present a solution for the development cycle of AI components [39,40].

The authors used the V-model methodology in the education sector for learning processes or in an IT organization for business architecture processes [12,37,41,42,43,44].

The use of the V-model in the development of mobile applications is also rare, but despite this, the review of the relevant literature brought several examples [18,45,46,47].

According to the literature review, we can state that not only is the use of the V-model significant, but combinations of other methods are starting to appear in the last period. Software development methodologies are included as a mainstream of agile software development and user-centered design. Agile software development relies on people and their creativity rather than processes to overcome problems with traditional software methodologies. User-centered design focuses on the goals and needs of the software’s end-users to deliver the appropriate software usability. It is important to focus on what customers consider valuable [12].

The article combines requirements development using the SCRUM agile methodology and the V-model in automotive development [48]. In other works, a software model V-SCRUM [24], or the Scrumming-in-the-V-Model during the implementation of large projects, were proposed [49,50].

Even though there are few practical articles on the use of SAFe in organizations, the authors provide a literature review on the experiences of organizations that have adopted SAFe [51,52]. Other articles presented the SAFe framework experience for implementing large enterprise resource planning projects in large [53,54,55]. According to the survey, literature documenting case studies on adoption and application in a real case is still rare.

The other articles mentioned refer exclusively to agile methods used in the health sector, which was our first research question (RQ1) for this article’s solution. Despite this, some articles describe the barriers to implementing a combination of agile methods [56,57,58,59,60,61].

Liu et al. used the V-model method to develop a platform for mHealth application design. This method combines the traditional waterfall method with feedback mechanisms in the agile development process (Scrum) to ensure that newly added features work properly. They implemented the solution in 7 sprints, and the V-model was chosen for the last step of software development and better justification of the defined project requirements from customers [62].

The authors present an article that conducts research within an organization in Ireland based on the software development life cycle (SDLC). The article presents the steps of medical device software development and the integration of agile practices with a traditional SDLC-driven plan. Upon completing this implementation, the organization identified cost savings and reduced rework required to implement change requirements [63,64]. In addition, some articles indicate that using an iterative method, such as the agile method in medical device software development, would improve the software development process [65,66,67,68,69,70]. Arandia, Garate, and Mabe present a methodology for designing and developing embedded medical devices while minimizing economic investment during periods of technical risk and supporting customer feedback [29]. In other cited articles, agile methodologies are used to develop software for crisis management during the COVID-19 pandemic [71] and to improve user interfaces in medical software [72].

Bombarda et al. present the experience with the certification of the MVM (Mechanical Ventilator Milano) mechanical ventilator software, on which an international and heterogeneous team of scientists for intensive care units collaborated during the first wave of the COVID-19 pandemic. Based on the published 24 guidelines, the article opens up the possibility of using agile methods together with documents controlled and stricter development processes [73].

Chiusaroli et al. present the design, development, and evaluation of a system for requesting imaging studies and estimating patient dosimetry levels in a public hospital. The evaluation study results show how the proposed system obtained a higher usability score than the existing system [74]. Khan et al. proposed an enhanced Agile V-model, the Enhanced Agile V-Model (EAV), for developing complex medical devices, and we applied its recommendation in developing our wave therapy device [75]. In the article by Tanniru et al., agile methodologies were used to develop reactive applications that can be used for elderly care in smart urban homes [76].

We can state that articles combining agile methodologies and their implementation or integration in the healthcare sector are very few available and published. From the articles published in this area, it is obvious that the results of the organizations and the activities of individual processes have improved, and the development time has been shortened. Customer requirements and software development cooperation were considered in individual steps, where the team and its management played a responsible role. Other benefits published in the articles include team communication and feedback from team members. Also, a gradual software development process focused on changes, where customer collaboration is considered. The adoption of agile software development in the healthcare sector has encountered several obstacles, such as lack of documentation, insufficient advance planning, regulatory compliance, low traceability of process and system maintenance, and management of non-functional or insufficient requirements [60].

4. Results and Discussion

4.1. The Case Study Application to the Organization

Although there is a growing body of literature on large-scale agile development, there is still a lack of literature documenting real-world experiences related to scaling agile frameworks. This paper aims to fill the practical experience gap by providing a case study on applying a combination of agile methods, V-model, and Product Lifecycle Process (PLP) in healthcare software development.

The organization chosen for the case study is an international corporation. Siemens Healthineers operates in several countries worldwide and is an umbrella organization for many medical device projects such as Ultrasound, CT, MR, RTG, etc. The organization has introduced modern approaches and initiatives in IT and project management. They are the basis for an agile way of working. Most of these projects use PLP projected onto a V-model for software development. The methodology and its practical implementation can differ from project to project, but this basic concept is followed on every project.

The roles and their responsibilities taken from the combination of PLP and V-model used in software development are as follows:

Product Steering Group (PSG)—the cross-functional team responsible for defining, planning and managing all activities and deliverables that are part of the project, including post-M300 product monitoring and control, under the guidance and authority of the Project Manager. PSG approves each milestone and presents the decision to the Management Team. Each PSG member is responsible for the deliverables of the process(es) that they represent. Each PSG member provides the Project Manager with the schedule, deliverables, and activities of their respective process and the identification of the resources included in the overall project plan. Also responsible for identifying key project and business risks.

Project Manager—PSG Leader. Responsible for organizing, planning and executing the project according to the Product Lifecycle Process.

Product Manager—PSG member. In the PMCD and early Define phases, the product manager provides analysis and a business case for product candidates. Responsible primarily for the Customer Requirements Specification and Product Validation activities

Business Analyst (BA) for PLM—PSG Member. The BA for PLM is responsible for assembling the Product and Service Financial analysis.

Customer Service (CS) Representative—PSG Member. Responsible for generating and executing the Customer Service Plan.

Compliance Engineering (CE) Representative—represented by the System Integration Manager on the PSG.

Marketing Sales and Communication (MSC) Head—Management Team member.

Technical Documentation Manager—Optional PSG Member representing the user/operator manuals.

Quality Assurance (QA) Representative—PSG member. This individual represents the Quality and Environmental Health and Safety organization on the PSG and is responsible for ensuring project adherence to Quality requirements and reviewing for adherence to Quality System processes.

Regulatory Affairs (RA) Representative—PSG member. This individual represents Regulatory Affairs on the PSG and is responsible for ensuring project adherence to Regulatory requirements and country registrations.

New Product Introduction (NPI) Project Manager—PSG member. The NPI project manager represents the SCM organization. The Manager is also responsible for Design Transfer and conducts the Production Readiness Review.

Strategic Purchasing Representative—PSG member. Responsible for purchasing and procurement for the project.

System Integration Manager—PSG member. Leader of the engineering system-level activities. Responsible for the execution of engineering deliverables of the project including product integration and verification.

Transducer Project Manager—Optional PSG member. Responsible for organizing and planning the project to achieve the project objectives and executing the project according to the Transducer Lifecycle Process a General Transducer Requirement Specification.

Product Lifecycle Management (PLM)—Head MT member and PLM organization.

Management Team (MT)—reviews deliverables at each milestone and decides, whether or not to proceed to the next phase. It includes the CEO, CFO, and Heads of PLM, MSC, SCM and QT.

Quality and Technology (QT) Head MT member—the person responsible for Regulatory Compliance. The QT Head supports the project manager in ensuring compliance and achieving product quality on all projects following the PLP. An individual has the right and obligation to stop projects if compliance or product quality is not ensured.

Supply Chain Manager (SCM) Head MT member—the head of SCM organization.

Head of Business Area—CEO of the Business Area.

Independent Reviewer—a trained individual with knowledge that will add value to the review process but who does not have direct responsibility for the content of the review subject. This individual is not the Author or the Moderator.

Moderator—a participant in a design review who records errors, issues, and actions and verifies that findings are dispositioned.

Phase Out (PO) Project Manager—responsible for product end-of-production, end-of-support and end-of-life planning/execution.

Product Portfolio Management—maintain product roadmaps and authorize the initiation of a project at the Commitment milestone. Also initiates the Phase Out of a product at the end of the product lifecycle.

Sustaining Project Manager—This person is responsible for organizing and planning a sustaining project to achieve the project objectives and executing the project according to the Product Lifecycle Process.

PSG is informed about the progress of software development accomplished by the teams in the Agile release train through close communication and collaboration between the Release Train Engineer (RTE), Software Release Manager (SRM) from the framework side and Product and Project managers from the PLP side. All risks and dependencies are actively resolved and managed. The results of such close collaboration are efficient and fast product delivery as documented by the past product release data.

In the following parts, this basic concept is presented—the application of V-Model and SAFe, quality assurance, and the observations and results of the implementation in actual conditions.

4.2. Application of V-Model

Because Siemens Healthineers—Ultrasound is part of a highly regulated industry, our development process is driven by FDA Engineering Lifecycle Management for Medical Devices, ISO 13485 Medical Devices, and the ISO 9001 Quality Management System [2,77]. ISO 13485 is an international standard for quality management systems in the medical device industry. It provides guidance and requirements throughout the life cycle of medical devices [77].

Consequently, we use PLP that is aligned with these standards. PLP organizes interdisciplinary project-related activities. It is a process used to define, plan, develop, launch, sustain, and eventually phase out our products. The process includes milestones used as quality gates as well as a representation of organizational agreement and commitment to support projects in subsequent phases by providing resources and finances as requested.

PLP Milestones:

• Roadmap and portfolio aligned with business strategies
• Market analysis, financial review, and budget for Phase 1 released

  2a

  Customer requirements specifications, initial go-to-market strategy, and clinical evaluation

• Business case and schedule commitment validation

  3a

  Realization concept definition

• Content, resources, and schedule committed by the organization

  4a

  Design and development complete

  4b

  System verification complete

  4c

  Safety and effectiveness review

  4d

  System validation complete

  4e

  Production readiness review

  4f

  Customer user test (CUT) ready

• Product release for customer user test (optional vs. milestone 6—at the discretion of Product steering group)

  5a

  Product field- and market-launch-ready

• Limited customer ship (optional vs. milestone 5—at the discretion of the Product steering group)
• Ship in quantity
• Product phase-out
• End of support
• End of life cycle

A practical representation of PLP to V-model projection is illustrated in Figure 3. Orange triangles and yellow diamonds represent the PLP milestones and quality gates that products need to reach during the project’s phases.

4.3. Application of SAFe

The SAFe release train is running in parallel to PLP, and it helps the business determine which features from the roadmap will be ready to be released in a particular release.

The following roles and their responsibilities in software development are defined in SAFe:

Software Release Manager (SRM)—responsible for assembling interrelated components and features in the planned release; schedule management; streamlining the release process by coordinating with different contributors, e.g., system engineers, system testers; DevOps; Quality and Release Train Engineer (RTE).

Release Train Engineer (RTE)—is a servant leader and Agile Release Train (ART) coach who facilitates ART events and processes and supports teams in delivering value. They communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

Agile Software Team—a cross-functional group of typically ten or fewer individuals with all the skills necessary to define, build, test, and deliver value to their customers. The team builds the technical solutions that our product consists of.

Product Owner (PO)—Agile team member primarily responsible for maximizing the value delivered by the team by ensuring that the team backlog is aligned with customer and stakeholder needs.

Scrum Master/Team Coach (SM/TC)—servant leader and coach for an Agile team who facilitates team events and processes, and supports teams and ARTs in delivering value.

In SAFe, teams’ cadence is driven by planning product increments (PI). These are three months-long chunks of work, and the expected outcome of the PI is potentially a shippable product. The aim is to accelerate flow, ensure smooth transitions, minimize hand-offs, delays, and reworks, and, thus, have features ready for release with as little waste as possible.

At Siemens Healthineers, we plan for longer terms because it is not feasible to deliver a feature to our customers in 3 months due to various regulatory hurdles that need to be cleared before we can ship the product to the end user. Our ambition is to deliver a release every six months, alternating between minor and major releases. To facilitate such plans, we gather the entire development organization for a “big” planning event once a year. In the weeks leading to the “big” planning, business representatives and product managers identify the set of features with the most potential, organize these around value, and propose the scope for at least two upcoming releases. During the planning event, teams work together in person to estimate the effort, identify dependencies and risks, coordinate the collaborations for identified dependencies, and mitigate activities for the risks. The planning outcome is the north star for developers for the next four PIs. Over the next 12 months, we will organize smaller plannings that we will use for progress check-ins and course correction of the big plan.

SAFe release train teams (software developers and human–computer interaction designers) continuously work on the features. Train metrics are collected and used to determine software development and delivery predictability. During this work, features move through SAFe KANBAN, and criteria allow the features to move from the state to ensure that quality and functional requirements are met once the feature is committed to a release. As the PLP milestones approach, train metrics allow the release managers to confidently establish which features can be committed into upcoming releases and track the work progress once the features are included in the release plan and teams are committed to delivering them.

In the context of the V-model: When the scope of the release is planned, feature teams, together with System engineers, start to break down user expectations into System requirements and Subsystem requirements, which are part of the right side of the V-model and are needed to reach 2a and 3a milestones. Human-computer interaction designers work on clinical workflows and UI in parallel. When both activities are performed, feature teams can start implementing the feature post-3a milestone.

Teams work on developing feature functionality, but testing activities are also performed simultaneously, i.e., testing starts as soon as functional pieces are ready. Unit and component tests (UT and CT) are developed for all the application code merged to source control. Due to regulations for medical software, UT coverage is very strict, especially for parts of the code tracked as potential hazards for the patient.

The testing and verification plan and strategy are on the right side of the V-model. These documents are created for every feature and describe all verification activities in detail. Feature team testers and the System verification team are responsible for the documentation and execution of all testing and verification activities for all features in the release. The verification lead ensures completeness of test activities at the integration (IT), subsystem (SST), and system level (SLT). If automation is possible, these tests are written by a software developer or dedicated automation tester within the feature team, and the verification lead simply documents successful test runs in the reports. It is very important to have thorough documentation of formal verification and validation for the eventuality of audits. These verifications and validations are documented in feature traceability matrices as proofs of execution. At the process level, these are incorporated as items on the KANBAN state change checklist, and when the feature reaches the KANBAN state “Done”, we know that all criteria for the PLP milestones 4a. are satisfied. Thus, the PLP and V-model are both well-meshed with the SAFe processes.

4.4. Quality Assurance

Quality is very important for Siemens Healthineers—we never compromise on quality. Our ambition is always to deliver full-featured quality products on time. However, suppose we discover late in the cycle. If a feature we have committed to for a particular release does not reach the required quality level, it is shelved until the next re-borrow or the original release is shelved. We have a process called PCR (program change request) for both eventualities. Using V-model and SAFe allows us to avoid such situations, as they are both financially and reputation-wise costly.

The key is to plan well and ensure that all activities, including testing, formal documentation, and feedback from clinical specialists, are part of our plans. Early feedback saves money when late changes are made in the release.

Changes in requirements, design specifications, and workflows are hard to avoid completely; therefore, we strive to iron out all the details early in the process. SAFe, as a framework implementing the agile methodology of software development, allows us to receive feedback from clinical professionals early by presenting our software as soon as we have functional increment that can be used in regularly scheduled Sprint system demos. This is critical because every late code change can potentially break the system’s functionality, especially in complex medical systems like ultrasound. If we did not have regular feedback from clinicians and instead relied on feedback after all originally planned functionality was finished, implementing the change from such late feedback would be costly. Not only would it require redesign, but also a repeat of all levels of testing that would have been already finished in this stage. Following SAFe and agile methodology is the key to addressing this potential risk, and close cooperation with internal clinical experts during the project’s entire lifecycle is a significant improvement and a necessity.

The testing process consists of several phases. Acceptance testing is the final stage before the system is accepted for operational use. It verifies whether the given software meets the customer’s requirements. Tests are performed in the customer’s operating environment based on a prepared plan. For some software products, it is impossible to conduct acceptance testing for every customer; therefore, alpha and beta testing are carried out.

Alpha tests take place at the software development workplace. The end user tests it, and the developers monitor it and note any issues. Selected users in their environment perform beta tests, and bugs are reported to developers. After errors are corrected, the final product is created.

Based on these principles, we assess the final validation according to established standards and procedures for software development. Our clinical specialists who represent our customers are involved in the individual steps of the final validation (alpha and beta tests). We hold special events called Internal Clinical Evaluation and External Clinical Evaluation, where external clinical professionals from the field perform final validations.

5. Conclusions

The application of complex medical device development, which involves translating innovative ideas into medical products, can be challenging.

Using the traditional Waterfall methodology can be slow and expensive as a team of developers works on large-scale tasks. It also invests heavily in creating a fully functional product before releasing it to users for testing and ultimately to the customer. However, if unexpected changes and interventions occur during validation and testing, the development of the medical device must return to the previous phase.

Using an agile approach helps accelerate the development journey by providing users with a device that is faster for testing and iterative revisions by the development team, leading to lower costs and faster delivery to customers, ultimately benefiting patients in need. As mentioned above, all projects at Siemens Healthineers use PLP and V-model. The first product that used agile methodologies was Acuson SC2000 PRIME, Siemens Healthineers Business Unit Ultrasound, a Cardiovascular Ultrasound System, which was kicked off in 2006. Agile methodology was adopted in the first year of development, and the project started to utilize agile principles and the SCRUM framework with early customer feedback. The timeline of releases varied from 1 year to three years. Including Internal Clinical Evaluation and External Clinical Evaluation has improved the developed product’s stability.

Development of the SC2000 successor, called the Acuson Sequoia Ultrasound System, started in 2017. The well-known V model, PLP process, and Scrum are used during product development. Kanban replaced pure SCRUM as it is more suited to the nature of our work, allowing teams to be nimbler and consequently enabling a smooth, uninterrupted flow of value to customers. Because we needed to coordinate a growing number of teams and scale our agile framework, in 2018, the Ultrasound division of Siemens Healthineers introduced the SAFe framework. With the implementation of the SAFe framework for Ultrasound product development, the predictability of releases has been greatly improved.

Currently, we can have major releases every 1–2 years. Acuson SC2000 PRIME had 5 major releases in the duration of 131 months (

Table 1. Major releases on Acuson SC2000 PRIME.

Major Releases	Duration
1.0	29 months
2.0	36 months
3.0	12 months
4.0	24 months
5.0	30 months

), i.e., 26.2 months per release. Acuson Sequoia had 7 major releases in the duration of 93 months (

Table 2. Major releases on Acuson Sequoia.

Major Releases	Duration
1.0	10 months
2.0	20 months
3.0	6 months
4.0	18 months
5.0	15 months
6.0	8 months
7.0	16 months

), i.e., 13.3 months per release. We can consider this improvement as an answer to the article’s research question (RQ2), and it represents an approximately 50% improvement compared to the development of SC2000, where SAFe was not used.

The combination of agile methods and the V-model brought the given organization advantages and a better position on the market from the point of view of the final customer’s satisfaction, which is the patient.

Using the chosen combination of agile methods and defined roles from SCRUM leads to a transparent review of individual steps by team members. Also, between teams and respective product owners. Thanks to this, the customer requirements are incorporated quickly, and the teams are more assertive about changes. The combination of methods makes evaluating the process and the result of the customer’s established requirements easier.

We can state that using the V-model and the SAFe framework makes it possible to deliver a quality product to the customer with incorporated changes and requirements on time. The key is planning and ensuring that all activities, including testing, formal documentation, and feedback from clinical specialists, are included. Of course, avoiding changes in requirements, design specifications, and workflows is challenging, so the effort is to fine-tune all the details early in the process. As a framework implementing an agile software development methodology, SAFe allows us to get feedback from clinical professionals by presenting our software promptly as soon as we have a working model. Implementing a change from late feedback would be costly without their regular feedback and instead relying on feedback from and after all originally planned features were completed. It would require not only a redesign but also a repetition of all levels of testing that would have already been completed at this stage. Adherence to SAFe and agile methodology is key to addressing this potential risk, and working closely with internal clinical professionals throughout the project lifecycle is not only a significant improvement but has also become a necessity.