Integrating Agile and the Systems V-Model: Proposing a Hybrid Solution

International Journal of Management and Humanities (IJMH) ISSN: 2394-0913 (Online), Volume-12 Issue-3, November 2025 13 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. Integrating Agile and the Systems V-Model: Proposing a Hybrid Solution Marc Berry, Venkata Allada Abstract: This study introduces an Agile Hybrid model that combines the Agile and Systems V philosophies for product development initiatives. Agile frameworks thrive in environments that offer supportive iterative development, continuous integration, and incremental delivery. The current literature introduces existing Agile Hybrid models, but they are presented only at a conceptual level. This leaves practitioners without clear direction on how to implement an Agile Hybrid framework in a complex, real-world scenario. Based on research and practitioner experience, the findings show that the primary challenges are executive understanding and communication links, cultural resistance, management of hardware integration, integration methods, and backlog management. Executives have reported feeling that planning is incomplete when using Agile. This proposed Agile V model provides a practitioner-centric approach to improving these challenges. The models consist of two main components. First, an Agile V Overlay—an Agile/Systems V visual roadmap that aligns Sprints to Gates and ties executive leadership's interests to the development team's work evolution— can be used for both project planning and execution. Secondly, a Comprehensive Adaptive Backlog (CAB) is an artefact repository that contains all engineeringand programmatic-type artefacts typically required for new product development initiatives. The CAB ties work artefacts to Sprints and to the Systems V gate review. Combined, the Overlay and CAB provide tools to help Project Managers and Engineering Managers plan and execute complex product development projects in a highly regulated environment. The goal is to provide tools that enable design evolution while maintaining a systematic, gated approach that supports regulatory compliance. The authors have conducted initial interviews with industry practitioners, which have yielded positive results for the model's utility. Practitioner feedback has been incorporated to fine-tune the model and improve its alignment with real-world applications. Future research will adopt a mixed-methods approach, including interviews with industry practitioners to continue validating the Agile V model. Keywords: Agile, Systems Engineering, Agile Hybrid, Systems Engineering V Model, Project Management, New Product Development. Abbreviations ADP: Acceptance Data Package Manuscript received on 24 October 2025 | First Revised Manuscript received on 29 October 2025 | Second Revised Manuscript received on 05 November 2025 | Manuscript Accepted on 15 November 2025 | Manuscript published on 30 November 2025. *Correspondence Author(s) Marc Berry*, Department of Engineering Management and Systems Engineering, Missouri Science and Technology, Rolla, US Minor Outlying Islands. Email ID: [email protected], ORCID ID: 0009-0002-80102471 Dr. Venkata Allada, Professor, Department of Engineering Management and Systems Engineering, Missouri Science and Technology, Rolla (MO), United States of America (USA). Email ID: [email protected] © The Authors. Published by Blue Eyes Intelligence Engineering and Sciences Publication (BEIESP). This is an open-access article under the CC-BY-NC-ND license http://creativecommons.org/licenses/by-nc-nd/4.0/ CAB: Comprehensive Adaptive Backlog CAD: Computer-Aided Design CDR: Critical Design Review CONOPS: Concepts of Operations EDU: Engineering Development Unit LLPL: Long Lead Parts Procurement Start MRR: Manufacturing Readiness Review PDR: Preliminary Design Review PIC: Program Integration Cycles POD: Parts on Dock PoP: Period of Performance SRR: System Requirements Review SVR: System Verification Review TRR: Test Readiness Review V&V: Verification and Validation XP: Extreme Programming I. INTRODUCTION In today's product development environment, Project and Engineering managers face the challenge of shorter time-tomarket and lower new-product costs. Basically, looking for products that are cheaper while maintaining the same level of quality excellence. Traditional project management methods, such as the Systems Engineering V-Model, provide a systematic structure, but often lack the flexibility to allow changing requirements [22]. This is particularly true when using an Agile framework with hardware-focused systems engineering projects, which can affect the traditional “pure Agile” approach. Systems engineering projects can benefit from Agile Hybrid methods, which combine Agile flexibility with structured approaches to achieve the same benefits as “pure Agile” methods in software design. The Agile V-Model helps address these concerns by integrating Agile and Systems Engineering V-Model principles to meet current research needs in new product development initiatives. The framework consists of two main elements: the Agile V Overlay, a product development lifecycle visual roadmap, and the Comprehensive Adaptive Backlog (CAB), an artefact repository that identifies and lists backlog requirements and aligns them with sprints and systems engineering V gate reviews. The Agile V Overlay in the model provides a highlevel visual overview of the product development process, while the CAB serves as a planning and execution tool for sprints. The framework enables management of physical products, as its categorisation of hardware-centric deliverables—Digital Modelling, Additive Manufacturing, Engineering Development Units, Qualification Units, and Qualified Design Units—shows a natural progression of hardware development through the Agile sprinting process. The integration of sprints with Integrating Agile and the Systems V-Model: Proposing a Hybrid Solution 14 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. Systems Engineering V gates and high-level engineering lifecycle phases enables executive leaders to track project performance as development teams execute. This solves the planning-incomplete issue that researchers and practitioners have identified and documented. Future research will validate the Agile V-Model through a mixed-methods approach that combines practitioner surveys with semi-structured interviews to assess quantitative effectiveness and qualitative insights into practitioner implementation. The dual evaluation method will provide an assessment of the model's usability and its potential for improvement across different industries and business sectors. This paper is structured as follows: Section 1 provides an introduction and overview of Agile practices and the Systems Engineering V-Model to establish the study’s context. Section 2 examines current research on the advantages and challenges of Agile and V-Model approaches. Section 3 describes the development process, while Section 4 outlines the proposed methodology for introducing the Agile V model. To conclude, section 5 presents proposed research paths for future work that the authors will conduct to evaluate model validation through practitioner interviews. Figure 1 below depicts the manuscript roadmap. [Fig.1: Manuscript Roadmap] II. AGILE OVERVIEW The agile methodology is a project management approach that breaks a project into sprints and emphasizes continuous collaboration and improvement throughout the project lifecycle. Teams follow a cycle of planning, execution and evaluation [1]. Agility goes back to the manifesto of agile software development, developed by a consensus of 17 programmers on how to work more efficiently than traditional approaches under uncertain and dynamic conditions [3]. The manifesto consists of four values and 12 principles. ▪ The precedence of individuals and interactions over procedures and tools ▪ Functional software is preferred to lengthy documentation. ▪ Prioritizing client interaction over contract deinitialization ▪ Responding to change rather than adhering to a predetermined course of action Agile approaches include Lean, Extreme Programming (XP), Scrum, and Kanban. Scrum is the preferred methodology because it works well with hardware and physical development [7]. Although agile comes in various forms, [7] suggests that Scrum is the most applicable to physical product development initiatives. A. Agile-Scrum [18] define Scrum as: Scrum is an easy method that helps people and teams generate value via changing solutions for complicated problems. In summary, the Scrum framework requires a Scrum Master to provide a working environment that: i. The work for a complex problem is ordered into a Product Backlog by a Product Owner. ii. During a Sprint, the Scrum Team converts a portion of the labour into an increment of value. iii. The Scrum Team and its stakeholders evaluate the outcomes and make necessary modifications for the subsequent Sprint. iv. Reiterate The Scrum framework is deliberately incomplete and straightforward, defining only the parts required to implement Scrum theory. Scrum is built on the collective intelligence of its users. Rather than providing detailed instructions, the Scrum rules guide people's relationships and interactions. Various processes, techniques, and methods can be employed within this framework. Scrum wraps around existing practices and renders them unnecessary, while making visible the relative efficacy of current management, environment, and work techniques so that improvements can be made [19]. The Scrum model, as described by [19], is iterative and includes three repetitive stages: product backlog development, main sprint, and daily sprints. Each iteration increases customer value [20]. B. Core Scrum Concepts i. Product Backlog: a prioritized list of work for the project team to complete. ii. Sprint Goal: Leading toward project milestones and deliverables. iii. Sprint Backlog: A selected subset of the artefacts that need to be completed that align with the sprint goal. iv. Sprint: a short development period (usually one to four weeks) aiming to complete the (incomplete sentence/thought) v. Sprint: Backlog includes agile events such as daily meetings, sprint planning, sprint demonstration, sprint review, and sprint retrospective. Section 1Intro & Overview •Roadmap •Agile Overview •Systems V Overview Section 2 - Literature Review •Agile Benefits and Challenges •Agile V Benefits and Challenges •Discussion Section 3 - Agile V Model Development Process •Practitioner Experience •Literature Reviw •Combined Similarities •Research Gaps Section 4 - Proposed Methodology •Agile V Overlay •Comprehensive Adaptive Backlog (CAB) Section 5 - Forward Work •Mixed-methods approach •Structured Interviews •Qualitative and Quantitative Questions International Journal of Management and Humanities (IJMH) ISSN: 2394-0913 (Online), Volume-12 Issue-3, November 2025 15 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. vi. Daily Meeting: Regular check-in to keep the team informed and on track to complete the sprint. vii. Sprint Planning: The first event of each sprint in which the team determines the sprint backlog, which is a subset of the product backlog. viii. Sprint Demo and Review: A sprint event in which the outcome of the sprint is first reviewed with stakeholders (demonstration) and against the sprint goal to help inform future work. ix. Sprint Retrospective: Final event of each sprint in which the team identifies ways to improve their agile practices. Another recent source [13], states Agile represents an iterative and incremental method which delivers value through flexible teamwork and continuous delivery instead of following strict long-term plans. The early 2000s brought forth Agile as a response to traditional project management philosophies that were inflexible when handling change. The Agile Manifesto, published in 2001, established formal Agile principles by presenting four core values and twelve guiding principles for project management. The Agile Manifesto establishes its core values through four fundamental ideals as follows: The Agile Manifesto prioritises individual team members and their interactions over all other organisational systems and technological resources. The Agile approach allows 1) higher importance to delivering operational software versus developing extensive documentation, 2) allows for team collaboration with customers instead of reliance on contract negotiations and finally, 3) supports flexibility and adaptation instead of maintaining strict project plans. C. Systems Engineering V Overview The Systems Engineering V-Model, as described by [14] is a framework that visually and conceptually outlines the systems engineering process in a unique "V" shape. This model encompasses aspects of system design evolution, from initial conception to final disposal [14]. states that the model incorporates key technical reviews, System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review (TRR), Manufacturing Readiness Review (MRR), and System Verification Review (SVR), which are major milestones used to ensure system design meets system requirements. The left side of the "V" identifies the requirements definition phase, laying the foundation for the system development phase. The systems engineering V model is used to manage systems engineering projects through the following Milestones, also referred to as gates. The systems V model, as described by [9], establishes it as a fundamental component of the systems engineering philosophy. Although there are many different V models with different nomenclature, the most common ones are as follows: SRR - A formal system-level review held to ensure system requirements have been identified and that a mutual understanding and agreement with all stakeholders exists. SRR establishes the functional baseline [9]. PDR - A formal system-level review that evaluates preliminary design fidelity by the results of requirements of trade studies, prototyping, and critical technology demonstrations. PDR will establish the allocated baseline and confirm that the system under review is ready to proceed into the next phase of system development with allowable risk agreed to by all stakeholders [9]. CDR - A formal system-level review that evaluates technical artefacts to ensure that a system can proceed into the next phase of system development, which consists of manufacturing and testing, and meeting stated performance requirements within cost, schedule, and risk [9]. MRR - A formal system-level review that evaluates if a product's design and manufacturing plan are ready for production, which identifies and mitigates any risks before manufacturing. Significant areas of an MRR review include checking the design, production processes, personnel, facilities, and quality management systems to ensure the product can be built on time, within budget, and to the required quality and quantity [9]. TRR - A formal system-level review that evaluates if a system is ok to start formal system testing by assessing test objectives, methods, procedures, and safety requirements. It ensures that all resources, such as personnel, equipment, and documentation, are in place. Additionally, it assures all stakeholders that the system has sufficient design and planning to proceed to the next phase. A successful TRR confirms that planned tests align with program requirements and user needs [9]. SVR - A formal system-level review that evaluates the system-level performance of the product by reviewing the verification reports to determine if the configuration end item meets its item performance specifications as documented in the allocated baseline post SRR review [9]. D. Benefits and challenges of Agile, Traditional and Hybrid methodologies Agile, Systems Engineering V-Model, and hybrid agile project management processes each have their own benefits and challenges. Based on the literature for each of these methods, an overview of the approaches, with their key benefits and challenges, is shown in Figure 2 below. Integrating Agile and the Systems V-Model: Proposing a Hybrid Solution 16 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. [Fig. 2: Agile Hybrid Benefits and Challenges] III. METHODOLOGY The Agile V model emerged from a combination of practitioner experience in product development, project management, and systems engineering, coupled with a comprehensive literature review that identified research gaps aligned with the authors' knowledge. Based on the literature, Agile methods have proven effective for software development, yet the strict, software-oriented Agile approach has been challenging to apply to hardware-based projects. The implementation of Agile principles as a standalone approach revealed significant deficiencies during the execution of established system engineering milestones, including the System Requirements Review (SRR), Preliminary Design Review (PDR), and Critical Design Review (CDR). To reconcile Agile implementation with Systems V requirements, a hybrid strategy was required. The Agile Systems V Model development process used a systematic approach that united field-practitioner knowledge with extensive research into deficiencies in project management frameworks. The development process consisted of four stages: documenting practitioner experiences, conducting a systematic literature review of Agile-Stage-Gate and Agile-V-Model combinations, and combining these findings to create the new Agile Systems V Model. A. Practitioner Experience The Agile V models' foundation was built on practitioner knowledge from projects that used both the Systems Engineering V-Model and Agile frameworks. The project management team gained specific expertise through their work with gate-controlled processes in controlled settings and their implementation of Agile techniques in software development projects. The team members showed intense interest in combining Agile's iterative methods with VModel-structured verification steps to improve efficiency and reduce overall time to market. B. Literature Overview on Hybrid Models The literature review identified four Agile hybrid models that integrate Agile with traditional methods for product development management as summarized in the following table. The findings show that Agile Hybrid models provide benefits in terms of improved time-to-market metrics, team communication and cohesion, and flexibility. Conversely, it shows challenges with management support, integration guidance, and model validation. These concepts are excellent in theory, but the proposed Agile V model delves deeper and provides tools for project planning and execution in complex product development projects. International Journal of Management and Humanities (IJMH) ISSN: 2394-0913 (Online), Volume-12 Issue-3, November 2025 17 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. [Fig.3: Agile Hybrid Model Comparison] C. Experience and Literature Review Synthesis The next phase of the Methodology combined knowledge from practitioner experience with the literature review. Findings show that both practitioners and peer-reviewed literature face similar challenges. Challenges include a lack of executive understanding of Agile, communication complications between executives and development teams, cultural resistance, and difficulties with hardware integration and Agile philosophies. The matching themes between these two domains strengthened the validity of the identified problems and identified the need for a hybrid solution to help close these gaps. This synthesis process used a systematic comparison of practitioner experience and academic findings to develop a model that combines theoretical foundations with real-world applications. D. Development of the Agile Systems V Model The proposed Agile Systems V Model was derived as a hybrid solution that combines Agile with the Systems Engineering V-Model. The model merges the traditional VModel into an Agile sprint-based structure while still maintaining requirement-to-verification traceability throughout the verification stages as defined by [14]. The model enables executive leaders to monitor program execution while providing development teams with a focused view of Agile work execution. This is needed because the executive team typically monitors project performance at a high level and is interested in the status of significant milestones. Secondly, the executive team usually consists of people who are not well-versed in Agile principles and understand the traditional, milestone-driven framework better. The model connects sprints with Systems V milestones through a central alignment representation visual system. The model provides a system-level milestone visibility tool for leadership oversight and a backlog management tool to identify and manage work artefacts for product development and regulatory conformance. The model integrates backlog management into the V-Model visual aid to define backlog content and maintain complete artefact tracking between sprints and systems engineering V milestones. The Agile Systems V Model integrates these features to solve the identified problems by (1) enhancing executive oversight, (2) handling system integration challenges and oversight, (3) considering constraints of physicality, and (4) establishing a method for backlog planning and management. The resulting methodology combines Agile flexibility with V-Model structure to address the research need across both practical applications and the literature. Figure 4 provides an overview of the Methodology development process. [Fig.4: Methodology] Integrating Agile and the Systems V-Model: Proposing a Hybrid Solution 18 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. IV. AGILE V MODEL INTRODUCTION [Fig 5: Agile V Core Concepts] The Agile System V-Model combines the Agile V Overlay with the CAB to create a practical framework for product development. The V Overlay shows how Agile sprints integrate within the Systems-V timeline structure. The CAB serves as the core organizational unit which enables project and sprint planning activities that executives often feel are lacking in Agile hybrid models. Iteration, Innovation, and Objective-Driven execution are the three main pillars of the Agile V Model. The integration of these components provides a structured method for product development. Iteration is achieved through the CAB management, Sprint Reviews, and Systems V integration. Secondly, Innovation is achieved by identifying new strategies for developing backlog artefacts, improving development efficiency, and advancing new technologies to enhance system development. Lastly, provide an ObjectiveDriven environment stemming from the systems V framework, which utilises Gate Reviews to drive execution rigour, improve leadership communication, and enhance overall PoP Management within a Sprint-to-Sprint Agile framework. Figure 3 highlights the model’s key components, which were derived from practitioners’ experience and the literature review. V. AGILE V OVERLAY The Agile V Overlay Model presents a visual representation that merges the systems V Model with the Sprint cycles throughout the product development lifecycle. This tool enables improved strategic planning, resource management, and risk and opportunity management. The extended planning cycle enables agile planning for work execution to align with traditional systems engineering milestones downstream of the product development lifecycle. The hybrid approach demonstrates potential to improve systems engineering concepts by combining adaptable methods with structured, milestone-based approaches. In summary, the overlay model is used to lay out the engineering lifecycle and tie Systems V gates to Sprints for planning. It also provides a mechanism to track the project's progress. Sometimes, project progress gets lost in sprints, leading to a loss of sight of the big picture. This overlay picture is helpful to the Executive and Development teams. The Agile Overlay is depicted in Figure 4. Gate Review Milestone & Engineering Lifecycle Phases definitions can be found in Appendix B. [Fig.6: Agile V Overlay] A. Sprints & Program Integration Cycles Integration with Systems V Milestones In typical Agile practice, sprints are fixed-length, timeboxed iterations in which cross-functional teams deliver incremental progress on system development. After sprint planning is complete, sprint execution begins. The sprint cycle concludes with a sprint retrospective that reflects on the sprint just completed. Its primary purpose is to enable the team to evaluate their performance, processes, and collaboration, identifying what went well, what could be improved, and how to implement changes for future sprints. The length of a sprint depends on organisational needs and the project's complexity. Typically, shorter sprints enable rapid adaptation in rapidly changing environments, while longer sprints allow for more thorough progress in more challenging environments. The model uses sprint duration to align with V-Model gates, enabling teams to deliver incremental work to support milestone goals while maintaining adaptability to requirement changes. PICs oversee team output coordination, manage larger work packages, and ensure program-wide goal alignment. PICs operate with a different approach than sprints, focusing on strategic alignment through larger work packages that help achieve program-level goals. Basically, the PIC philosophy provides a longer planning cycle than a typical 30-day sprint to enable longer-term planning. International Journal of Management and Humanities (IJMH) ISSN: 2394-0913 (Online), Volume-12 Issue-3, November 2025 19 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. B. Sprint-to-Milestone Alignment Sprints 1 through 3 produce artefacts which serve as review packages for the System Requirements Review (SRR). The three sprints included all backlog items from the CAB required to fulfil SRR requirements. Sprints 4–6 focus on producing the artefacts required to support the Preliminary Design Review (PDR). These sprints address all backlog items identified in the CAB that are critical to achieving PDR objectives. In addition to monitoring and updating the artefacts created during Sprints 1–3, new efforts focus on advancing specifications, refining requirements, and maturing programmatic plans, such as make/buy strategies, supplier management approaches, and risk mitigation planning. The development of Critical Design Review (PDR) supporting artefacts continues through Sprints 7–11. The development work from Sprints 4–6 serves as the base for these sprints, which complete all backlog items from the CAB to achieve PDR objectives. The current phase requires teams to enhance specifications and requirements, advance make/buy plans, and refine supplier management approaches. The team develops essential plans and procedures to help the project meet downstream review requirements and system delivery needs. The design engineering work during these sprints’ advances from 10–20% drawing development to more mature design stages, reaching a 90% drawing completion readiness level to support CDR. The expanded engineering output serves two essential purposes: delivering vital information for the PDR assessment and laying the foundation for the Critical Design Review (CDR) phase. The development of Manufacturing Readiness Review (MRR) supporting artefacts continues through Sprints 12–17. The systems engineering process builds on the design maturity from Sprints 7–11, progressing toward manufacturing and production readiness. The remaining backlog items from the CAB which match MRR requirements are focused on fulfilling both technical and programmatic requirements to complete MRR. The teams enhance system requirements to production requirements while making final purchasing decisions for tooling and manufacturing readiness. The development of detailed manufacturing procedures, assembly plans, quality assurance protocols, and configuration management systems continues to support production capability verification efforts as part of the MRR. The design engineering process moves forward with drawing development that reaches complete definition for production, fabrication, and integration purposes. Sprints 18 through 19 consist of all the necessary work required to conduct a TRR successfully. All required artefacts under the input criteria are identified in the CAB. This is the point in the project where a transition occurs from manufacturing to systems testing readiness review. The primary intent of these sprints is to develop the artefacts for the required testing documentation, testing facility readiness, testing personnel readiness, and testing equipment needed to conduct the system test. The development of System Verification Review (SVR) supporting artefacts occurs during Sprints 20-23. The System Verification Review (SVR) requires this phase to demonstrate that the manufactured system fulfils all requirements. The system design and manufacturing outputs are validated through extensive testing during Sprints 20–23, demonstrating that the product meets all contractual and customer requirements. The program achieves readiness for the System Verification Review through these deliverables, which also create a base for acceptance and operational readiness transition. The main objective of Sprint 24 is to complete and review all necessary artefacts that will enable system delivery to the customer. The system uses verified outputs from Sprints 20–23 and SVR success to create delivery-ready products and documentation. The sprint focuses on completing CAB backlog items that fulfil delivery needs and meet contractual, technical, and logistical requirements. The sprint produces complete configuration management records, test reports, and quality artefacts necessary for customer buy-off. The sprint also unifies supplier close-out packages with compliance statements to prove complete requirement fulfilment throughout the supply chain and product development lifecycle. The artefacts produced during Sprint 24 serve as complete proof of program completion, enabling a system that fulfils requirements and meets stakeholder expectations while being operationally ready. A comprehensive listing of all artefacts and their definitions is in Appendix A. A comprehensive listing and description of lifecycle phases is available in Appendix C. C. Strategic Milestone Alignment Bars The Agile V-Model operates through two distinct communication pathways that target different stakeholder groups via the Executive/Leadership Bar and the Development Bar. The Agile V Overlay includes tools that address the ongoing challenge of connecting executive oversight to Agile development. Typically, executives are more familiar with traditional project management frameworks and can’t see the “big picture” within Agile cycles. The Executive/Leadership Bar shows the overall development status of major V-Model milestones, including System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), Manufacturing Readiness Review (MRR), System Verification Review (SVR), and Delivery. VI. CAB OVERVIEW The CAB is a tool that will maintain and monitor all backlog artefacts which fulfil compliance and regulatory needs throughout the PoP. The categorisation method creates a unified system that links work artefacts to sprint cycles and major Systems V milestones for monitoring across agile development cycles and gate reviews. The CAB establishes a logical sequence for physical deliverables, consisting of the Digital Modelling, Additive Manufacturing, Engineering Development Unit, Qualification Unit, and Final Qualified Design Unit stages. This framework identifies typical hardware evolution that “pure Agile” systems struggle with. The CAB identifies backlog orders, which guide teams on work sequencing by working all artefacts in parallel rather than following a sequential finish-to-start method. The parallel processing method speeds up development schedules while maintaining flexibility, which supports the model's goal of merging fast development with controlled systems engineering practices. The CAB serves as an adaptable starting point for Agile V-Model artefact Integrating Agile and the Systems V-Model: Proposing a Hybrid Solution 20 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. management, which organisations can customise to meet their specific organisational and regulatory requirements. The CAB aligns with various compliance requirements and project needs through its adaptable design, which supports traceability and scalability. An overview of the CAB is depicted in Figure 5 below, and the complete CAB is attached in Attachment 1. [Fig.7: Comprehensive Adaptive Backlog (CAB)] A. Backlog Artefacts The CAB serves as the core element of the Agile V-Model by creating a flexible database which expands the standard Agile backlog to support hardware-based and regulatory requirements. The system captures all engineering artefact deliverables, which include digital models, engineering drawings, design information, test plans, test reports, compliance documentation, and certification evidence. All this accumulated evidence is typically referred to as the ADP (Acceptance Data Package), which contains all the necessary information customers require to accept the deliverable hardware. There are two things to deliver in large-scale systems engineering development products: 1) the physical hardware itself and 2) the documentation that shows compliance with regulatory requirements. The items follow a structured arrangement that links to essential V-Model stages, including SRR, PDR, CDR, MRR, SVR, and Delivery, to meet program targets and comply with regulatory standards. The CAB enables flexible Agile iteration and milestone-driven oversight through its product structure, which supports teams in managing complex changes and maintaining compliance throughout the entire process. B. Digital Modelling The process of digital modelling starts with hardware development, including the creation of virtual system representations such as sketches, 3D models, and simulations. The Agile V-Model requires this work to be completed during the first sprints to achieve the SRR and PDR milestones. In some cases, there could be physical models and prototypes by the SRR/PDR timeframe. The team conducts multiple rounds of model enhancement based on stakeholder feedback, producing CAD drawings and simulation artefacts. The CAB tracks output origins through its management system, and the Agile V Overlay allows teams to connect their work progress to milestone assessments for performance tracking by both team members and executives. The iterative approach allows designers to make quick adjustments that would be challenging to achieve in the standard V-Model process. C. Additive Manufacturing The process of additive manufacturing creates physical prototypes from complete digital models through 3D printing to verify fit, form, and, if applicable, functional performance. The stage is prepared for the Critical Design Review. The iterative prototyping process in sprints enables teams to evaluate hardware concepts by testing prototypes, which produce experimental results and material analysis findings. The CAB contains items that meet the review requirements, and the Agile V Overlay monitors progress toward the milestone. The process reduces development time by enabling quick feedback cycles that outperform conventional sequential prototyping. D. Engineering Development Unit (EDU) The Engineering Development Unit integrates mechanical and electrical components into a working prototype, enabling complete system testing. The EDU needed multiple development sprints leading up to the Manufacturing Readiness Review to reach mechanical integrity and basic functional performance validation readiness for teams. The EDU units typically start after the PDR, as the design begins. EDU units are used for preliminary testing at early stages of the design. The Agile V Overlay system provides an effective way to identify where in the process the system design is. From experience, executives International Journal of Management and Humanities (IJMH) ISSN: 2394-0913 (Online), Volume-12 Issue-3, November 2025 21 Retrieval Number: 100.1/ijmh.C185012031125 DOI: 10.35940/ijmh.C1850.12031125 Journal Website: www.ijmh.org Published By: Blue Eyes Intelligence Engineering & Sciences Publication (BEIESP) © Copyright: All rights reserved. sometimes get lost in sprints and struggle to see the big picture, especially when it comes to physical product development cycles. E. Qualification Unit The EDU validation process results in the creation of qualification units, which must undergo formal testing and verification in operational settings. Qualification unit development typically begins after CDR approval, as the milestone establishes the product baseline. The CAB tracks environmental test data, compliance data, and verification/test reports generated during this stage to verify compliance with requirements. F. Fully Qualified Design Unit The last production phase produces operational-ready hardware products that have completed qualification. The last stage of the sprint includes completing integration work, user acceptance testing, and preparing qualification documentation. The CAB verifies that all artefacts, such as compliance evidence and final design packages, are finished and have proper traceability. The Agile V Overlay represents the final stage of performance, which unites flexible iterative work with strict milestone-based monitoring. G. Development Artefact Allocation to Sprints and Milestones The Agile Systems V-Model uses the CAB as its central repository for all artefacts needed to complete the project scope within organisational and regulatory requirements. It uses a systematic approach to identify and distribute artefacts between sprints and milestones by placing each item before assigning it to a sprint and Program Integration Cycle (PIC) while connecting it to its supporting Systems V milestone. The Agile V Overlay contains completion points that indicate when artefacts must be completed, and start points that define when work activities must begin. The philosophy is that all artefacts should start at the same time (Authorisation to Proceed) and progress through the product development process. The goal is to execute tasks in parallel (start-to-start) rather than serially (finish-to-start). VII. DISCUSSION The Agile Systems V Model combines the philosophies of Agile and the Systems Engineering V Model to address four main concerns identified in the literature and practitioners' experience. The four concerns are 1) Integration complexity, 2) backlog management, 3) executive oversight, and 4) constraints of physicality. The previous frameworks showed Agile and Stage-Gate principles could work together, but they did not provide specific operational methods for their integration. The Agile Systems V Model resolves this gap by integrating the Agile V Overlay & CAB. The Agile Systems V Model is a theoretical framework that requires experimental testing to demonstrate its effectiveness. The model needs further research to determine how backlog prioritisation, cost management, and resource distribution should operate within large, function-based teams. A question that arises is: “What type of organisation structure supports an Agile V model?” Additionally, understanding how travel time would impact the workflow and backlog is essential. Would Earned Value Management, which is typically used in traditional methods, be used in the Systems V model? In realworld scenarios, all work isn’t always completed on time, so if the job is not completed within planned sprints, does that uncompleted work initiate a new sprint? Or is the current sprint prolonged? The model requires additional research to develop operational elements and test its ability to scale up for practical implementation. To complete model validation, future work will use a mixed-methods research design to assess the Agile Systems V Model through surveys and semistructured interviews to capture practitioners' experience. VIII. CONCLUSION & FORWARD WORK The Agile V Hybrid Model serves as a practitioner-centric framework that combines Agile adaptability with the Systems Engineering V-Model's systematic structure. The model enables sprint alignment through milestone reviews via the Agile V Overlay and CAB, which support planning and execution while also inhibiting executive oversight. The Agile V-Model provides a visual framework that enables organisations to implement theoretical models for managing highly regulated software and hardware projects. The manuscript offers both theoretical and practical aspects of the framework. Yet, future studies need to demonstrate their operational value through mixed-methods research that combines practitioner interviews with industry case studies to evaluate their practicality, effectiveness, and broader applicability. The Agile V Hybrid Model enables researchers and practitioners to tackle current product development challenges through its adaptable framework, which incorporates oversight elements for innovative work. The proposed Agile V-Model validation will use a mixed-methods research design, which combines survey data with semistructured interview responses to collect feedback from practitioners who use Agile in their actual work environments. The surveys will use Likert-scale questions to measure practitioner satisfaction and system development process improvements, and to collect quantitative data about model effectiveness, usability, and project outcome impact. The research will use semi-structured interviews to gather qualitative data that will help practitioners explain their experiences, present their challenges, and propose improvements. The mixed-methods approach will validate the Agile V-Model, demonstrate its real-world usability, and reveal potential enhancements. Initials have been completed, and the initial findings do show positive signs. Some findings provided valuable suggestions for model improvement, which have been incorporated. DECLARATION STATEMENT After aggregating input from all authors, I must verify the accuracy of the following information as the article's author. ▪ Conflicts of Interest/ Competing Interests: Based on my understanding, this article has no conflicts of interest. ▪ Funding Support: This article has not been funded by any organizations or agencies. This independence ensures that the research is conducted with objectivity