Modern vehicles rely on millions of lines of code to deliver advanced features in autonomy, connectivity, electrification, and mobility services. Traditional development approaches struggle to keep up with the rapid pace of change and innovation required. To remain competitive, automotive manufacturers and suppliers are increasingly adopting agile methodologies at scale – embracing iterative development, cross-functional collaboration, and responsiveness to change.
Agile promises faster time-to-market and improved flexibility, which are crucial as software becomes a key differentiator in automotive products.
However, implementing agile in the automotive context is far from trivial. Automotive systems are safety-critical and highly complex, integrating software with hardware and mechanical components under stringent regulatory standards. Many organizations have decades of plan-driven, V-model processes tailored for compliance and quality assurance. Transitioning to agile requires reconciling iterative development with safety standards that assume waterfall lifecycles. It also demands cultural change in large engineering organizations and their supplier networks. As a result, while agile methods have shown success in small-scale software teams, scaling agile for large automotive programs exposes significant requirements engineering (RE) challenges. Requirements engineering – the practices for eliciting, specifying, and managing requirements – becomes a critical discipline to rethink in order to support agile at automotive scale.
Recent studies have shed light on these challenges. Kasauli et al. conducted a multi-case study involving seven large product development companies (including two major automotive firms) to identify RE challenges in large-scale agile system development. Their findings reveal pain points in understanding customer needs, handling changing requirements, maintaining system knowledge, and aligning processes and organizations with agile principles. In parallel, industry practitioners and researchers have reported similar hurdles in applying agile methods to automotive projects, such as difficulty complying with safety regulations, balancing documentation with working software, and coordinating numerous stakeholders. These challenges underscore that agile requirements engineering in automotive is an evolving discipline requiring new practices, tools, and mindsets.
In this article, we explore key requirements engineering challenges that automotive organizations face when adopting large-scale agile development, and discuss how they can be addressed. We focus on findings from Kasauli et al.’s work, interpreting the challenges through an automotive lens, and we integrate insights from other studies, frameworks (like SAFe and LeSS), industry case reports, and professional experiences. We will examine:
For each area, we discuss practical solutions proposed in the literature and by frameworks (e.g. Scaled Agile Framework and Large-Scale Scrum) as well as emerging best practices from automotive companies. We also highlight gaps where current approaches fall short and identify opportunities for further improvement or research. The goal is to provide automotive RE and agile leaders with a comprehensive view of the landscape and actionable guidance on navigating the journey to large-scale agility.
One cornerstone of agile is an intense focus on customer value – delivering working product increments that satisfy user needs and gather feedback. In the automotive domain, however, bridging the gap to the customer is particularly challenging in requirements engineering. Large automotive programs often involve layers of stakeholders between developers and end-users (drivers, owners), including product managers, marketing, dealers, and even regulatory bodies. Agile teams can feel several steps removed from the actual customer experience. Kasauli et al. found that across large organizations, teams struggled to understand how their daily work provides real customer value. In all the studied cases, companies had dedicated roles (such as Product Owners or requirements engineers) to channel information from customers and other stakeholders down to the development teams. Direct developer-user interaction was rare, as it could disrupt established processes or simply be infeasible (you can’t have an end-user “on site” full-time for a car project). This distance leads to a risk that teams become focused on implementing backlog items without a clear line of sight to the end-user value or context.
An automotive agile team often works on a small part of a feature (a “sub-feature”) that fits in a short iteration, whereas the full feature (e.g. a new driver-assist function) is what actually delivers value to the customer. One interviewee in the study noted “a feature is what is sold to the customer”, but teams were so occupied with following agile rituals that they sometimes neglected the big picture of product value. In the automotive cases, requirements typically flow from internal functional management or systems engineering units, not directly from end customers. This can lead to user stories that carry little obvious user value – they may describe a low-level sensor calibration or interface, for example – making it hard for team members to see how it impacts the driver’s experience. As a result, there is a danger that customer value gets lost in translation as requirements are decomposed across many teams.
Frequent feedback loops with real users are also difficult in automotive. Unlike a web app where users can be continuously engaged, car features often can’t be deployed to customers until a vehicle program milestone. Feedback thus arrives infrequently and late. Indeed, one automotive case reported “long and complicated feedback cycles” – by the time actual user feedback on a feature comes in, teams have moved on and may barely recall the context.This delay stems from slow hardware integration schedules and customers who are not accustomed to evaluating partial product increments. The result is that agile teams lack timely customer insight to inform requirements evolution.
How can automotive organizations build and maintain customer value understanding in their agile teams? Several practices help mitigate the customer gap:
Despite these efforts, bridging the customer gap in automotive remains non-trivial. Research highlights a need for more concrete techniques and tools to establish and validate a shared understanding of customer value in large-scale contexts. Unlike consumer software, automotive development cannot rapidly A/B test features or continuously deploy to production for real user data. Thus, surrogates for customer input – like simulations, digital twins, and focus group feedback – become very important. One promising approach is leveraging connected car data: for example, capturing how customers actually use current features (via telemetry) and feeding those insights into requirements for the next iteration. This closes the loop from actual usage back to requirement refinement, albeit with careful attention to privacy and ethics.
In summary, automotive agile teams must work extra hard to keep the customer in the loop due to organizational distance and long feedback cycles. By institutionalizing customer-centric practices (frequent demos, strong Product Owner function, cross-functional collaboration), companies can reduce the gap. As we’ll see next, the challenge of responding to change is closely tied to understanding customer needs – when feedback does arrive or market conditions shift, the requirements system must be ready to adapt.
Changing requirements are a fact of life in any agile project – “embrace change” is a core agile principle. In the automotive sector, requirements change management becomes even more delicate due to long product lifecycles, safety implications of changes, and coordination across many teams and components. Large automotive programs must support continuous evolution of the requirements baseline as new insights emerge, while avoiding chaos in a complex system-of-systems. Kasauli et al. identified “Support Change and Evolution” as a major challenge area, detailing several specific issues: handling experimental requirements, synchronizing multiple development efforts, encouraging reuse over re-specification, and keeping requirements updated over time.
One facet is the treatment of experimental or innovative requirements. Automotive companies often start developing a new product with many unknowns – for example, exploring a novel AI driver assistance feature. These experimental requirements (essentially research-oriented or speculative features) don’t fit neatly into the regular sprint backlog process. Interviewees noted that if you strictly follow short sprints, you may not allocate enough time for exploratory work or proof-of-concepts needed to validate a new technology. Conversely, if you spin off research separate from the agile teams, you risk a disconnect when integrating that research back into the main requirements stream. One manager in Kasauli’s study asked: should we have “learning and increment planning sprints” specifically for exploration? Some case companies indeed introduced dedicated innovation sprints or spikes to handle experimental requirements outside the regular delivery cadence. This aligns with SAFe’s concept of enabler stories and set-based design for exploration – allowing teams to spend time prototyping multiple alternatives before committing to one solution. The idea of set-based design, borrowed from lean product development, is particularly useful in automotive: instead of upfront specifying one design, teams can concurrently develop several approaches (for example, two different battery management algorithms) and later converge on the best, thus keeping requirements flexible during early development. The challenge is managing these experiments so that they eventually merge into the main development without derailing planning. SAFe’s solution intent artifact can be used to capture evolving design decisions and assumptions during experimentation.Nonetheless, establishing a clear approach for handling experimental requirements in agile automotive projects remains an open research area – organizations are still learning how to blend R&D activities with iterative delivery.
Another challenge is synchronization of development when different parts of the organization move at different speeds. In automotive, it is common to have hardware development, software development, and system integration all proceeding in parallel. Hardware and mechanical development cycles tend to be longer and more sequential (it might take months to fabricate a new ECU or sensor prototype), whereas software teams aim to deliver increments in weeks. This mismatch can lead to waiting times and integration nightmares. Kasauli et al. observed that in their cases, there were “differing levels of agile pervasiveness” – some teams (often software) were highly agile, while other departments (hardware, safety engineering) followed more plan-driven approaches. Aligning these is difficult. One Automotive case noted that software feedback was gated by hardware availability, delaying end-to-end testing and customer feedback. Additionally, multiple agile teams working on the same product need to coordinate to avoid conflicting changes. A common mitigation is to establish rhythms for synchronization. For instance, SAFe prescribes a biweekly Agile Release Train (ART) sync meeting and regular Program Increment (PI) planning events where all teams plan together face-to-face. These rituals create checkpoints to align on requirements changes, integration points, and dependencies. Some automotive organizations hold “big room planning” every 8-12 weeks, gathering representatives from software, hardware, testing, and even suppliers to jointly re-plan and synchronize their backlogs to the updated requirements baseline. Beyond formal events, companies have used tribes, chapters, and guilds (borrowing the Spotify model) to improve cross-team communication on evolving requirements. For example, a System Architects Guild might meet weekly to ensure that each team’s new user stories are not diverging from the overall architecture and to discuss change impacts. LeSS similarly encourages continuous improvement and multi-team retrospectives to coordinate change across teams. Still, effectively synchronizing development in a large-scale automotive agile program requires significant effort. Research suggests that new techniques (and possibly tooling support) are needed to manage multi-speed development and to propagate changes systematically across many teams.
A critical principle for managing change is to avoid unnecessary re-specification and encourage reuse. In long-lived automotive product lines, there is often a wealth of existing requirements and components from previous vehicle models or variants. Yet, agile teams starting a new feature might inadvertently rewrite requirements or duplicate functionality if they are only focused on the immediate sprint scope. One challenge reported is moving the mindset from “project-based” requirements (where each project starts from scratch) to a product-focused approach that leverages existing assets. Kasauli’s study noted that adopting product line engineering principles can speed up development – i.e., treating common features and requirements as reusable modules and explicitly reusing them across projects. Automotive companies are leaders in product line engineering (e.g., a company-wide requirement for “airbag deployment” might be reused in dozens of car models). The agile transformation must incorporate this by giving teams access to a central repository of baseline requirements and pushing for reuse rather than reinventing the wheel. Both SAFe and LeSS promote a product (rather than project) focus: SAFe, for example, organizes teams around product features and capabilities, and LeSS warns against duplicating product functionality across teams. One practical action is to have an architecture or systems engineering function maintain a set of core requirements (or reference stories) that teams consult before writing new ones, to see if an existing solution can be extended. Additionally, avoiding overly narrow product definitions ensures teams consider the broader scope; LeSS suggests avoiding a narrow product scope to prevent duplicate solutions and instead having a wide product definition so that feature teams naturally reuse and collaborate. Despite these approaches, scaling reuse in an agile setting still needs systematic guidance. Organizations may need to invest in requirements knowledge management systems that make it easy for agile teams to find and adapt existing requirements (e.g., a well-indexed database of user stories and acceptance criteria from past projects).
With continuous change, another necessity is keeping requirements artifacts up to date. In a fast-paced development, requirements evolve, and it’s easy for specifications or backlogs to fall out-of-sync with the current product. This is problematic in automotive where, at the end of the day, you still might need a complete requirements set for compliance or maintenance. The study found that teams often lacked concrete practices for updating requirements after implementation – many treated requirements as “write once” documents that were not maintained as code changed. One company tackled this by treating requirements like code: using version control (Git) and peer review for requirement changes, similar to code changes. In that approach, called T-Reqs internally, any update to a requirement (like a user story description or a spec detail) had to be committed in a repository and reviewed via Gerrit just as a code patch would be. This ensured traceability of changes and a living requirements document. Additionally, forming communities (guilds or chapters) focused on requirements health can raise awareness – for example, a “Requirements Chapter” that periodically reviews if backlog items and documentation are aligned with the latest decisions. LeSS literature acknowledges that requirements will change and not all remain equally important; it suggests accepting that some requirements may be retired or lose priority over time, which is fine as long as the team has a way to know the current state of the requirements space. The key is having transparency: teams and management should always have an up-to-date view of what the agreed requirements are, even as they evolve. This might involve using integrated Application Lifecycle Management (ALM) tools that link user stories, tasks, and higher-level requirements and make changes visible to all stakeholders.
From an industry perspective, automotive organizations also must integrate formal change control where needed. Even when using agile internally, companies still have to perform impact analysis on requirements changes due to safety processes (ISO 26262 mandates evaluation of the impact of any requirement change on hazard analysis, for instance). A balanced approach is emerging: allow agile teams to propose and implement changes rapidly, but institute a lightweight change management process on top, to review and sign off significant requirement modifications for safety or regulatory impact. Rasheed et al. (2020) highlight that frequent changes and missing requirements are challenges in agile RE, and they advocate formal requirement models and change control as potential solutions. For automotive, this could mean modeling requirements (for example, in UML or Simulink) such that changes can be analyzed for consistency and completeness before they are accepted – though in practice, formal modeling at scale is hard to sustain and requires skilled staff. Some companies opt for a middle ground: they use traceability matrices and hazard tracking to ensure each requirement change is evaluated, but they time-box the analysis to not stall agile progress.
In summary, managing change in automotive agile projects requires blending agile flexibility with the rigor of systems engineering. Promising practices include special handling of experimental requirements (using spikes, set-based design), strong multi-team synchronization mechanisms (PI planning, cross-team meetups), fostering reuse and product-line thinking to avoid redundant work, and treating requirements as living artifacts that are continuously updated and governed. All of these aim to ensure that as requirements evolve – which they inevitably will – the project remains under control and aligned. The next set of challenges we’ll explore deals with how teams maintain a shared understanding of the system and keep requirements clear and connected as they iterate rapidly.
In large automotive projects, no single developer or even team can hold the entire system in their head. Requirements are spread across various subsystems – powertrain, infotainment, driver assistance, etc. – and each agile team works on a slice. This creates a risk that local decisions diverge from the overall system needs, or that teams lose sight of important cross-cutting requirements (performance, safety constraints, compatibility). Kasauli et al. categorize several challenges under “Build and Maintain Shared Understanding about the System”, which include ensuring sufficient documentation (even in agile), reconciling system vs. component viewpoints, creating and maintaining trace links, preserving knowledge over time, and handling backward compatibility. All these speak to a common tension: agile methods value “working software over comprehensive documentation,” yet in complex systems, some documentation and systematic communication are essential for shared understanding and compliance.
Documentation vs. working software is a delicate balance in automotive. Traditional processes produce extensive requirement specifications, design documents, and test plans before coding starts. Agile flips this by emphasizing executable software and minimal just-in-time documentation. The challenge is that automotive projects still need certain documents – for example, requirements for homologation or safety cases. Kasauli’s study found that agile teams often had to supplement user stories and acceptance tests with additional documentation to capture interfaces, dependencies, and rationales that wouldn’t emerge from code or tests alone. Case companies reported using models and text summaries to complement user stories – for instance, interface control documents or SysML models that describe how components interact. One automotive team created a high-level systems architecture model accessible to all teams; while daily work was in user stories, the model provided a “big picture” reference of system behaviors and was updated at each increment. SAFe similarly advises using models to analyze requirements where appropriate (for example, performance modeling, or state machine diagrams for complex behaviors). This documentation supports understanding things like timing budgets or safety requirements which might be hard to infer from individual stories. The difficulty is to do just enough documentation – too little and teams lack clarity, too much and it bogs down agility. Practitioners note that complying with formal standards (like ISO 26262 for functional safety) via agile is hard precisely because those standards expect a certain set of documents and evidence. Many automotive firms end up with a hybrid: they maintain some traditional documents (perhaps at a high level) but manage detailed development through agile backlogs. This can cause duplication and extra work. As Notander et al. observe, safety standards being prescriptive and waterfall-oriented leads to tension – teams can find it “difficult to comply with domain standards through an agile method”. There is ongoing experimentation to resolve this, such as tools to auto-generate documentation from agile artifacts or new agile-friendly interpretations of safety processes. For example, researchers have proposed creating “Documentation Work Items” that exist alongside user stories, ensuring tasks for producing required documents are tracked in the same way as feature work. In aerospace (a similar domain), a tool was used to generate certification documents from requirement databases automatically – automotive could leverage similar ideas. Ultimately, while agile teams should not return to writing 100-page specs upfront, they do need a strategy for lightweight documentation that accumulates as the system evolves. The concept of an “agile documentation” approach is emerging: continuously documenting key decisions, assumptions, and requirements in parallel with development, often in a wiki or model repository that is incrementally updated. This keeps the system knowledge current and shared without a big bang documentation phase.
The issue of system vs. component thinking is closely related. In Kasauli’s findings, teams sometimes became myopic, focusing only on their component’s user stories and losing the overarching vision. In an automotive context, consider a team responsible for the climate control software; if they only think in terms of their backlog, they might miss how a change impacts the overall vehicle electrical load or the user’s comfort experience when interacting with other features. To prevent siloed thinking, it’s important to establish a global understanding and ownership structure for requirements. Companies have tackled this by defining clear breakdowns of requirements from the system level to teams. SAFe’s requirement model (epic → capability → feature → story) is one way to reflect the hierarchy: epics and capabilities capture system-level needs, which are then decomposed into features and stories for component teams. The study notes that having architects on each team or an “architect owner” role helps to enforce system thinking – these are team members who deliberately look beyond the team scope and consider impacts on other parts. Some organizations use periodic system integration demos where all teams see how their pieces come together, which reinforces a holistic perspective. LeSS encourages whole product focus as a principle, meaning teams should be concerned with product-level goals, not just their local tasks. In practice at BMW and others, this has meant rotating people through different teams (spreading knowledge) and making product-level metrics (like end-to-end performance or customer satisfaction) visible to all teams, so everyone is motivated to optimize for the system, not just their component.
Traceability is a perennial requirements engineering concern that becomes acute in agile automotive projects. Traceability refers to the ability to link requirements to corresponding design elements, implementation, tests, and verification results. In safety-critical automotive systems, demonstrating traceability from high-level safety requirements down to code and test cases is often required by standards. Yet, agile methods, with their fast-moving user stories, can make traceability seem like an afterthought. Kasauli et al. identified “Creating and maintaining traces” (Challenge C3.c) as a significant gap – traces were deemed valuable and often mandated, but “rarely provide direct value to their creators” (developers), leading to them being neglected or done inefficiently at the end. In several case companies, they found a dual system: formal requirements existed in a document (for compliance) and agile user stories existed in backlogs, but the link between the two was weak or manual. One product owner admitted that while traceability was required, his focus was on getting the feature working and not on “documenting the function” for trace links. The result is that when it came time to do an audit or impact analysis, teams had to scramble post-factum to create trace links between user stories and system requirements, a very inefficient process. Clearly, this is not sustainable.
Potential solutions to the traceability issue involve both process and tool innovation. From a process standpoint, one recommendation is to bake traceability into the Definition of Done for user stories – e.g., a story is only “done” if any new or changed requirements are traced to higher-level specs and test cases are linked. Some agile teams in regulated environments adopt this discipline to prevent traceability debt. Tools can also help: modern requirements management tools (Jazz, Codebeamer, etc.) offer integrations where each user story or backlog item can be linked to a requirement ID and test case. If teams use such an ALM tool consistently, trace links can be captured as a natural part of work. The Kasauli study mentions ideas like treating features as reusable requirement modules which inherently carry their trace links. For example, define a feature once along with all its sub-requirements and test cases, then if that feature is used in a new car model, you simply reference it (traces included) instead of rewriting it – this was noted as a practice in one manufacturing case. LeSS suggests lightweight ways to document traces, such as linking backlog items to wiki pages that describe higher-level requirements, keeping at most a 3-level hierarchy for simplicity. This can be sufficient for many functional requirements. But for strict compliance, more formal tracing might be needed. The gap in guidance is evident: Kasauli et al. note it is “slightly concerning how little scaled agile frameworks discuss tracing”. SAFe touches on traceability indirectly via its Solution Intent artifact (which is basically a repository of requirements and design decisions meant to be updated continuously), but it doesn’t prescribe exactly how to maintain trace links. Thus, there is a research and tooling opportunity to develop agile traceability approaches – ones that provide benefit to developers (so they’re motivated to do it) and not just overhead. One approach could be automating trace capture: for instance, using commit messages or issue tracking data to auto-establish links between code changes, stories, and requirements. Another is visualization: giving teams a quick visual trace graph to see the impact of a requirement, which might encourage them to keep it updated. Until such innovations mature, many automotive agile projects handle traceability through a parallel “documentation track,” which is costly. It’s an area needing improvement for true agility.
Closely tied to traceability is long-term knowledge management. In agile, teams may produce less formal documentation, relying on tacit knowledge and code as the documentation. But automotive products have long lifecycles – a piece of code or requirement might need understanding a decade later when a recall or update occurs. If key knowledge left only in people’s heads, attrition or reorganization can mean that knowledge is lost. Kasauli et al. label this challenge “Learning and long-term knowledge”: how to ensure knowledge persists beyond individual sprints and beyond team turnover. One finding was that encouraging ownership of features can help – when a team (or a subset of team members) owns a feature, they maintain its documentation and “teach” others when needed. Some companies deliberately rotate team members through different areas (feature and component teams) to spread knowledge and avoid silos. Communities of practice (guilds/chapters) are again beneficial, as they create networks where knowledge is shared informally across team boundaries. LeSS even suggests practices like “specification by example” – writing specifications in the form of executable scenarios or tests – which serve as living documentation that new team members can learn from. The idea is to treat requirements and tests as a knowledge base. Reflection workshops (post-mortems, retrospectives) where teams document lessons learned about requirements (e.g. “we misunderstood this requirement initially, here’s why and what to do next time”) are another method to capture knowledge. Ultimately, requirements engineering in an agile automotive context can be reframed as a knowledge management problem: the organization must continuously gather, refine, and disseminate knowledge about the product and its requirements. New approaches – perhaps leveraging knowledge bases, AI assistance to document decisions, or improved training – could be explored to ensure that even as teams iterate quickly, the important knowledge is not lost in the shuffle.
Finally, a specific system-level challenge in automotive is backward compatibility. Vehicles and their software endure for many years, and updates must not break existing functionality or compatibility with other components. In agile, the drive to deliver new features could risk overlooking constraints needed for backward compatibility. Kasauli’s study highlighted this as challenge C3.e – ensuring new increments remain compatible with older versions or interfacing systems. One case company’s approach was to push responsibility and freedom to the developers – essentially trusting teams to account for backward compatibility in their Definition of Done and giving them autonomy to design with backward compatibility in mind. This works only if developers are aware of compatibility requirements in the first place. Making such quality attributes explicit as part of the backlog (for example, having acceptance criteria like “must work with previous app version data”) is important. Notably, neither SAFe nor LeSS provide explicit practices for backward compatibility; it falls under general quality and architectural considerations. The research gap here is to devise systematic ways to manage backward compatibility in iterative development. Some techniques could include automated regression test suites that specifically test old-new component interactions, or deprecating features in a phased manner with clear requirements states. In automotive, one sees the use of standardized communication interfaces (like CAN signal contracts or AUTOSAR interfaces) to help maintain compatibility – agile teams updating a module must respect those interface contracts unless a major version change is planned. So, part of the requirements for each component includes its interface contract as an unchanging constraint during a release cycle, which is a kind of requirement that transcends any single user story. Teams need to treat those as non-negotiable requirements that always must pass tests. In summary, maintaining a shared understanding of the system in agile automotive development means documenting just enough of the right things, fostering system thinking in all teams, keeping traceability and knowledge flow alive, and not forgetting long-term concerns like compatibility. This is challenging, but with conscious practices and tool support it can be achieved, enabling agility without losing the rigor that complex automotive systems demand.
Agile development introduces new ways of representing requirements – chiefly user stories and acceptance criteria – which differ from the traditional, often formal requirements documents. In large-scale automotive projects, this shift raises questions: How do we map high-level stakeholder requirements to many fine-grained user stories? How do we handle non-functional requirements like safety, performance, reliability in an agile backlog? Are our tools (e.g. issue trackers, wikis) adequate for handling thousands of requirements? And how do we maintain consistency and quality of requirements definitions across dozens of teams? These concerns fall under what Kasauli et al. describe as “Representation of requirements knowledge” challenges. Essentially, it’s about how requirements are written down, structured, and managed in agile at scale.
One challenge (C4.a) is managing requirements at multiple levels of abstraction in an agile setting. Classic systems engineering distinguishes stakeholder requirements, system requirements, and component requirements in a neat hierarchy. Agile tends to use a flatter backlog of user stories. Automotive projects still need a notion of levels – a regulatory requirement (e.g. “The vehicle shall meet emission standard X”) might decompose into system requirements for the engine control and exhaust systems, which further break into stories for software and hardware teams. In agile, teams may struggle to trace that chain because the backlog is not inherently hierarchical in the same way. Kasauli’s study noted that mapping requirements to levels of decomposition is hard when using agile methods. Teams often ended up with an implicit hierarchy: epics representing big customer features, stories for team-level work, etc., but ensuring consistency between these levels was challenging. A proposed practice from the cases is to allow stakeholders to specify requirements at any level, but maintain traceability between levels. In other words, if a safety engineer writes a system-level requirement, it should link to the relevant user stories in team backlogs. This requires a requirements structure spanning from high-level to low-level, even if managed in agile tools. SAFe provides a model for this with epics -> capabilities -> features -> stories, essentially creating a requirements information model that transports the stakeholder’s view down to the component tasks. LeSS simply uses a Product Backlog with parent-child relationships and advises not to go beyond three levels deep of splitting. The key is to prevent agile teams from ignoring higher-level requirements. One automotive company implemented a practice where every user story had to cite which system requirement or feature it was contributing to; if it didn’t map to a higher requirement, why was the team doing it? This helped maintain alignment. Another practice is supporting distributed requirements analysis – e.g. having multi-team workshops to break down an epic into stories together, so that each team understands the context of their piece. Getting this right ensures that agile artifacts (stories) collectively still fulfill the intent of the system requirements. It’s noted that further guidance is needed on how best to do this decomposition in agile, especially in managing both customer-facing requirements and internal system requirements and linking them. This is an active area for process improvement.
Non-functional requirements (NFRs), such as performance thresholds, safety integrity levels, security, etc., also need careful representation. Traditionally, NFRs might be captured in a separate section of a spec or as quality attribute scenarios. In agile, teams sometimes forget NFRs until later or treat them as add-ons. The studied companies found it useful to express some NFRs as quantifiable thresholds that could be attached to backlogs and tests. For example, instead of a vague requirement “the system shall be responsive,” an agile-friendly expression is “system response time < 200ms for 99% of requests” which can be tested continuously. One practice was to negotiate such thresholds early and make them part of the Definition of Done (so that any story affecting response time must keep the system under 200ms, for instance). SAFe recommends handling NFRs as constraints at the program level that then constrain the backlogs of teams – meaning the NFR is not a story that gets “done” once, but an ongoing requirement that all relevant user stories must comply with. In automotive, safety requirements (like an airbag deployment time or a fail-safe behavior) function this way. They’re often managed as part of a system backlog or specification rather than as individual user stories. To ensure NFRs are not neglected, one company created a policy that every sprint review must report on certain NFR metrics (e.g., current memory usage, timing, etc.), thereby making NFR status constantly visible. LeSS doesn’t explicitly define how to handle NFRs, which suggests this is an area where organizations must develop their own conventions. The research community calls for better strategies to manage and evolve quality requirements in agile, as it remains challenging to handle them with user story-centric methods. Some suggest formulating NFRs as tests (e.g., safety tests, performance tests) that are automated and run in each iteration, effectively binding the NFR to the development cycle.
Another issue is that many existing requirements management tools are not fit for agile purposes (C4.c). Traditional requirements tools (like IBM DOORS) excel at hierarchies, traceability, and handling thousands of requirements, but are often cumbersome and don’t integrate well with agile boards or DevOps toolchains. Conversely, agile tools (like Jira, Trello) are great for team-level task management but lack the rigor needed for large-scale requirements tracking (e.g., baselining, versioning, complex trace queries). Kasauli’s study found complaints that tooling was “not fit for purpose” – teams ended up using a mix of spreadsheets, wikis, ticket systems, and none gave a holistic view. For example, one automotive department tried to use a Scrum tool for backlog management but had to supplement it with a separate database to record formal requirements for their quality process, leading to duplication. LeSS acknowledges that most ALM tools don’t natively support a single backlog for large products, so they mention that no specific tool perfectly handles a multi-site large backlog and that many organizations hack together boards, spreadsheets, etc., to manage. There is active development in this space: some vendors are creating agile requirements management tools that allow hierarchical backlogs, direct linking between requirements and code, and fine-grained access control for large teams. The case companies in the study resorted to simple solutions like having the Product Owner update requirements in a master document when teams finish a story, or teams maintaining their portion of requirements manually – clearly not optimal. The need for better tooling tailored to large-scale agile is evident. Ideally, a tool should let an automotive project manage high-level requirements, user stories, tests, and traces in one place with ease of use such that developers will actually use it. Until such tools are mature, organizations often designate a requirements coordinator role to manually ensure information flows between systems (for instance, syncing Jira user stories with a DOORS module periodically). This is a stop-gap measure and prone to error. Investing in tools or even building custom integrations (some companies write scripts to link Jira with their requirements repository) can pay off by reducing the manual overhead.
A related representation challenge (C4.d) is accommodating different representations for different teams while maintaining consistency. In a huge project, not every team writes requirements the same way: some might use strict user story templates (“As a driver I want…”) while others might still write technical requirements or use model-based specifications. Kasauli et al. noted that teams often had individual “flavors” of user stories and definitions of done, which was fine for local efficiency but made it hard to ensure overall consistency. On one hand, you want to emphasize team independence – allowing teams to adopt practices that suit their context (perhaps a hardware team prefers a more document-centric approach while a cloud software team is entirely Jira-ticket-driven). On the other hand, at the program level you need some alignment (e.g., a common understanding of severity levels, or uniform use of terminology) so that when information is rolled up, it makes sense. Companies addressed this by establishing cross-team “Ways of Working” guidelines – essentially a minimal process standard that all teams agree to. For example, a guideline might be: all items that impact external stakeholders must be phrased as user stories with clear user benefit; internal technical tasks can be tracked differently but must link to a parent story. Communities of practice were used to share these conventions and discuss deviations. One successful approach was having an agile coach or RE coach network that regularly audits how teams write requirements and helps calibrate if one team is doing things too differently. The balance between team autonomy and system-level consistency is delicate; more research is needed on how to strike it. Possibly, the solution lies in tooling again – e.g., a tool that enforces certain metadata on every requirement (like labeling whether it’s a functional story, an NFR, etc.) but lets teams format their work items flexibly otherwise.
Ensuring consistent quality of requirements across all teams (C4.e) is the final representation challenge. Poorly written or ambiguous requirements can cause defects and rework, especially when multiple teams must interpret them. In an agile context, requirements quality might be evaluated by how well acceptance criteria are defined or how clearly the user story expresses the need. The study noted practices like peer reviews of requirements (teams reviewing each other’s user stories) and having system managers or architects review for consistency. Some companies operationalized quality by capturing experience-based rules: for instance, a checklist derived from past lessons (“no acronyms without definition in a story”, “every story has a testable acceptance criterion”, etc.) and making teams follow it. There were also communities of practice and guilds to align on what “good” requirements look like. SAFe and LeSS themselves don’t provide explicit criteria for requirement quality, beyond general guidance; thus it falls on organizations to create their own quality norms. The notion of “just enough” requirement detail is often cited – meaning the requirement should be detailed enough to avoid misinterpretation but not so detailed as to constrain the team’s solution or waste effort. Achieving this at scale is tricky. Some teams will naturally be more rigorous than others, so leadership may need to invest extra coaching in teams that churn out vague user stories. Empirically evaluating different methods (for example, does training in writing user stories improve defect rates? Does using behavior-driven development for specification improve clarity?) would help, and Kasauli et al. call for more evidence on what works in practice to share experiences across industry..
In conclusion, representing requirements in a way that scales means blending hierarchical requirement models with agile backlogs, treating non-functional and regulatory requirements as first-class citizens in the backlog, upgrading tooling to handle large-scale requirement data, standardizing just enough across teams to keep consistency, and ensuring every requirement written meets a quality bar. Automotive organizations that manage this can enjoy the benefits of agile (responsive, iterative delivery) while still retaining the clarity and control of good requirements engineering. Those that don’t may encounter confusion, missed expectations, or compliance gaps. The next section builds on this by examining how the process and planning aspects themselves need adjustment in large-scale agile RE.
Adopting agile in a large automotive project isn’t just a matter of writing user stories and doing stand-ups; it also demands rethinking planning, prioritization, and coordination processes that were designed for sequential development. Kasauli et al. identified a set of process-related RE challenges (challenge area 5) that include how to prioritize distributed functionality, manage completeness of requirements, maintain consistent requirements processes across teams, and balance quality with time-to-market pressure. These challenges highlight the friction between agile methods (which favor continuous planning and decentralized control) and the realities of large-scale project management (which need alignment, predictability, and thoroughness).
Prioritization of distributed functionality (5.a): In a single-team agile project, prioritization is straightforward – one Product Owner orders a single backlog. In a large automotive program, there are multiple teams and possibly multiple backlogs (often split by subsystem or component), yet the features cut across them. How do we ensure that the most important customer features are prioritized globally, and that teams are working on the right things in the right order? This is essentially a requirements prioritization problem at scale. The case companies noted using a business or product dashboard to help rank requirements across different areas. For example, an OEM might maintain a top-level backlog of features with rough business value and cost estimates, and use that to guide team-level backlogs. One approach is Weighted Shortest Job First (WSJF), a technique championed by SAFe, which combines value, timing imperatives, and effort size to score and sequence work. SAFe provides constructs like a Portfolio Kanban and Program Kanban to manage cross-cutting initiatives and ensure that, say, an important customer-facing epic doesn’t get lost among technical chores. Another practice is holding joint backlog refinement sessions where multiple team Product Owners review and adjust priorities together, especially for items that require coordination. LeSS, on its side, recommends having one Product Owner as the single source of prioritization for the whole product – meaning even with many teams, there is one ordered backlog (often achieved by having a big overall backlog that teams pull from). In an automotive context, this could be challenging due to scale, but some companies attempt it by having a hierarchy of POs (chief PO, area POs, etc.) who align frequently so that effectively one voice is steering priorities. Multi-site product backlog reviews are another tactic when development is geographically distributed. A specific challenge is the classic “split to realize, then realize to split” problem – splitting features for teams can obscure the priority of the whole, so it’s critical to keep sight of the end-to-end feature. The consensus from research is that more empirical evidence is needed on what prioritization strategies work best at scale. Nonetheless, for RE in agile, it’s vital that the requirements prioritization process is transparent and connected from top to bottom. Automotive projects have multiple competing concerns (customer features, compliance items, technical enablers), so a structured prioritization scheme (like WSJF or risk-based prioritization) helps ensure the important things don’t fall through the cracks. Additionally, some companies incorporate cost of delay into decision-making – for instance, if delaying a certain requirement (like compliance to a new regulation) would incur heavy penalties, that feeds the priority calculus.
Managing completeness (5.b): Traditional RE places a big emphasis on completeness – have we captured all requirements? Agile, by design, may intentionally start with a minimal set of requirements (think MVP – Minimum Viable Product) and evolve, which conflicts with the completeness mindset. In safety-critical automotive projects, missing a requirement (especially a safety or regulatory one) can be disastrous. Interviewees in the study expressed concern on how to ensure no critical requirement is omitted when working in incremental slices. The authors noted no obvious solution in SAFe (in fact, SAFe’s principle of “implement incrementally and get feedback” might seem opposite to upfront completeness). LeSS offers the guideline “take a bite” – essentially, don’t try to do everything at once, which again doesn’t directly solve completeness. This suggests that to ensure completeness, organizations might need a hybrid approach. One recommendation is using checklists or taxonomies of requirements to systematically think through areas that might be overlooked. For example, an automotive RE team might maintain a checklist of common requirement categories (functional, legal, safety, environmental, manufacturing, service, etc.) to review whenever defining scope for a new feature or increment, ensuring something important isn’t forgotten. Another is performing periodic holistic reviews of the product requirements. Some companies schedule an “Architecture and Requirements sprint” at certain intervals where they step back from user stories and assess the overall requirements set for gaps. In an ongoing agile process, this could correspond to a PI boundary in SAFe where broader system analyses happen. The study calls for a clear language to reason about completeness in incremental work. One could imagine formalizing “did we cover all scenarios?” by using techniques like use case maps or model-based approaches to check coverage. For example, model-based systems engineering (MBSE) tools can simulate whether all operational modes have requirements specified. In one case, an automotive company combined agile with a preliminary phase of identifying high-level use cases and hazards – basically an initial requirements sweep – to secure critical needs, then let teams elaborate the rest during development. This hybrid “some upfront, some emergent” approach is also echoed by Ågren et al., who suggested using a lightweight upfront RE to capture key domain requirements and then filling details post-development with precise specifications. In summary, while agile eschews the notion of complete requirements up front, automotive projects likely need to complement agile with techniques to avoid omissions, at least for high-risk requirements. It’s an area where further methodological innovation (like continuous requirement lists that are validated by simulation or test for completeness) could help.
Consistency of requirements processes (5.c): In a scaled environment, different teams may interpret agile practices differently – one team might diligently update a requirement wiki, another might just use sticky notes; one might do extensive backlog grooming, another might be more ad-hoc. This inconsistency can hinder collaboration and quality. The challenge is to have some consistent requirements process without stifling team agility. The study observed that some companies solved this by defining that each sprint deliverable includes not just code and tests but also any requirement/spec updates as needed. This creates a uniform expectation: all teams deliver updated documentation along with code. Another practice was establishing a clear hierarchy from enterprise level to team (again, having a uniform backlog structure) and emphasizing team independence within that structure. Essentially: align on what needs to be done and documented at each level, but give teams freedom on how they do it. Communities of practice for “ways of working” are useful to share processes across teams. For instance, a Requirements Engineering guild can harmonize how user stories are written, how reviews are done, etc., across all teams. This yields a more consistent process. If one team finds a better way (say, they start doing three amigos meetings for each story – a practice where developer, tester, and PO discuss a story before implementation), the guild can propagate that to other teams. The research gap here is guidance on balancing alignment and diversity. Too much enforcement (making every team follow a rigid template) could slow things down, while too little (everyone does what they want) leads to chaos. Automotive organizations often resolve this by a defined process baseline (especially for things affecting safety or compliance) that all must follow, combined with continuous improvement where teams can propose changes to the baseline. For example, a company might mandate that every change must be peer-reviewed and traced (baseline rule) but allow teams to decide their meeting cadences or internal task breakdown (flexible part). This is analogous to the concept of “defined governance with local autonomy”. It aligns with what Kasauli et al. saw: some governance of requirements across levels was put in place, but teams were given responsibilities to update and manage requirements in their scope. Striking the right process balance is an evolving practice – frameworks like SAFe provide templates, but each company tailors them to fit their culture and regulatory needs.
Quality vs. time-to-market (5.d): The automotive industry is under intense pressure to reduce development cycles (sometimes dubbed “race to market”), especially with tech competitors like Tesla pushing rapid software updates. Agile is supposed to help with faster delivery, but there is a risk of cutting corners on quality (both in requirements and in the product) to meet short-term goals. The challenge is to maintain high quality of requirements and final products while still achieving speed. Kasauli’s study notes that frequent reviews of requirements relative to what was delivered in the sprint can help ensure quality isn’t compromised. This means, for example, at sprint review or system demo time, the stakeholders not only check the product increment but also review whether the associated requirements (user stories, etc.) were satisfied and whether any new requirements emerged. It’s a way of continuously validating requirements quality. SAFe emphasizes Built-in Quality as a core principle – all work should meet quality standards at every step, rather than testing quality in later. They also encourage using techniques like value stream mapping to eliminate delays so that speeding up doesn’t mean skipping necessary steps. A practical interpretation in RE context is ensuring requirements are good enough early so that they don’t cause rework later (which would hurt both quality and time). One automotive best practice is conducting mini “quality gates” in each increment for critical aspects. For instance, have a safety engineer quickly assess any new safety-related requirements introduced in an iteration, rather than waiting for a big safety review at the end. This catches issues when they are small. Additionally, leveraging automation can reconcile quality and speed: e.g., using automated analysis tools to check requirements language for ambiguities or using test generation to ensure every requirement has at least one test case. By automating quality checks, teams can move fast without letting quality drop. The concept of “just-enough” quality is interesting – guidelines to achieve sufficient quality in requirements, design, and testing to meet objectives without over-engineering. This means not gold-plating requirements (e.g., writing overly detailed specs for trivial things), but also not being so minimal that misunderstandings occur. Determining “just enough” often comes from experience and retrospective learning. Many agile automotive teams have learned by trial – if a defect is traced back to a poorly specified requirement, they adjust their practices to add a bit more rigor next time for similar cases. Over time, the organization calibrates its requirement quality level to where speed and quality are balanced.
In summary, process-level challenges in agile RE for automotive revolve around coordination and discipline at scale: prioritizing what matters most across many teams, making sure no critical pieces are missing, keeping teams on somewhat the same page process-wise, and pushing for speed while upholding quality. Addressing these requires both top-down structures (like common prioritization schemes, baseline processes) and bottom-up engagement (teams collaboratively refining how they work). Many automotive firms find that adopting a scaled agile framework (like SAFe) gives them an initial structure for these processes – e.g., SAFe introduces roles like Solution Manager, events like PI planning, and artifacts like Solution Intent that inherently tackle some of these issues. Others mix and match methods, or evolve their own “agile scaled” process over time. The key for requirements engineering is ensuring that amidst fast cycles, the process still enforces requirements discipline – meaning clarity, completeness, alignment are monitored continuously, not left until a big phase at the end. Next, we look at organizational and structural aspects, which often are the hardest to change in large companies.
Beyond team practices and processes, large-scale agile adoption in automotive often runs into higher-level organizational impediments. Established automotive companies have organizational structures, governance, and culture built around plan-driven development (think separate departments for systems engineering, software, testing, etc., with staged handoffs). Shifting to agile requires organizational changes: breaking silos, redefining roles, and sometimes restructuring how programs are funded and delivered. Kasauli et al. identify “Organizational aspects” as a challenge area (challenge area 6), including sub-challenges like bridging plan-driven and agile approaches, planning verification & validation (V&V) around requirements in agile, allowing time for innovation and upfront planning, and dealing with infrastructure impacts. Let’s unpack these in the automotive context.
Bridging plan-driven and agile (6.a): Many automotive firms do not have the luxury of a pure greenfield agile implementation; instead, they have hybrid models. For instance, they may still have to pass formal gate reviews or comply with a corporate development process (often aligned to Automotive SPICE or other standards) that prescribes certain documents and milestones, even if internally teams are agile. This creates a challenge of alignment: how to make agile teams productive while still satisfying plan-driven governance? Kasauli’s study found that a dedicated governance of requirements across levels was helpful. For example, some companies set up an Agile Requirements Committee that meets regularly to oversee the requirements state across the program – effectively replacing the old notion of a requirements review board with a more continuous governance body. They also allowed teams and Product Owners to update requirements directly, rather than funneling all changes through a single change control board. This empowerment speeds up agility but requires trust and verification (hence the governance group to monitor). SAFe provides a structural solution by implementing a clear hierarchy from enterprise to team and using artifacts like Solution Intent and architectural runways to connect the levels. However, the research highlights a gap: we need better strategies to replace static, document-heavy coordination mechanisms with “actively managed boundary objects” that serve the same purpose in a more agile way. A boundary object could be something like a continuously updated model or a set of test cases that all teams refer to, instead of a big spec doc. For instance, one OEM moved its requirements specification into an online wiki, which became a living document updated sprint by sprint. That wiki served as the boundary object between different teams and between development and testing – it was always current, unlike a traditional spec that would be outdated soon after creation. This helped bridge the gap: managers and quality auditors could look at the wiki (plan-driven need for documentation satisfied) while teams worked on user stories that updated the wiki (agile approach). Another example of bridging is maintaining dual process mapping: some companies explicitly map agile artifacts to traditional ones (e.g., a sprint backlog to a “software requirement subset” document, a PI increment to a milestone deliverable) to satisfy stakeholders who require the traditional view. Over time, as confidence in agile grows, these legacy mappings may be phased out, but during transition they provide reassurance that nothing is falling through the cracks. Culture also plays a role – some staff, especially in safety and management positions, might be skeptical of agile’s less formal approach. It’s crucial to involve them early, perhaps run pilot projects to demonstrate that agile can still meet plan-driven objectives (on quality, traceability, etc.). Bridging plan-driven and agile is often about changing mindsets: showing that agile does not mean “no discipline” but a different kind of discipline. Kasauli et al. indicate that research should continue to develop guidelines for this bridging, as many organizations are still figuring it out.
Planning V&V (verification and validation) based on requirements (6.b): In traditional development, there’s a well-defined V&V phase and test plans derived from requirements documents. In agile, testing is continuous, but at scale, not all testing can be fully continuous (e.g., crash tests or endurance tests on vehicles happen later). The challenge is how to plan and execute V&V activities in alignment with an evolving set of requirements. The case companies found value in establishing virtual test rigs and simulation models early, and managing requirements and tests together as they evolve. This has been a big push in automotive: using Model-in-the-Loop (MiL), Hardware-in-the-Loop (HiL) simulation, and test automation so that as soon as a requirement is implemented, it can be verified in a lab setting, without waiting for a full prototype vehicle. For example, if an agile team develops a new braking control software feature, a simulation environment can test its performance against requirements (stopping distance, etc.) immediately, rather than waiting for integration into a physical car. By linking requirements to test cases (a practice known as requirements-based testing), whenever a requirement is updated, the corresponding test is identified and can be run. SAFe’s concept of Solution Intent (a repository of requirements and design) linking to tests supports this, as does the idea of a dual-track backlog where test items mirror requirement items. LeSS emphasizes cross-functional teams which include test capability, meaning teams should not only write the feature but also write and execute its tests continuously. Some automotive programs set up an “integration test team” that works one sprint behind the development teams, continuously integrating and testing the outputs against system requirements – a rolling integration approach. The study suggests that proven approaches in this area are still developing; indeed, it’s a challenge to figure out how much early testing can truly be done when some tests need the real hardware. But even there, techniques like virtual hardware or rapid prototyping boards help. The underlying principle is to avoid the big-bang system test at the end by pulling as much testing as possible into the ongoing process, guided by the requirements. Another organizational aspect is making V&V a shared responsibility: agile culture says “quality is everyone’s job”, which in automotive means testers, developers, and requirement engineers working together from day one. Companies like Volvo reportedly use the concept of “scrum teams take full-stack responsibility” – they write requirements, code, and test for their feature, and only a minimal external system test is left at the end. That requires upskilling and support (like having test labs available to teams on demand). In summary, aligning V&V with agile in automotive is about continuous testing, earlier validation via simulation, and tight linking of tests to requirements all along.
Time for innovation and planning (6.c): Classic stage-gate processes often include phases for concept development and innovation before locking down requirements. In agile, the team is always executing in short cycles, which can paradoxically leave little time to think ahead or innovate beyond the immediate backlog. Automotive companies fear losing the long-term innovation if everyone is just focused on the next sprint. To counter this, SAFe builds in Innovation and Planning (IP) iterations – essentially, every few sprints, an iteration is reserved for hackathons, learning, and big-room plannin. The case companies also employed practices like maintaining a Solution Intent repository not just for current requirements but also future solution ideas. This is like a placeholder for long-term thinking – an area where ideas, potential requirements or architectural evolutions are stored until there’s time to address them. Enabler stories, as mentioned before, provide a way to schedule work that is not directly delivering a customer feature but is needed for future innovation (like refactoring, research spikes, technical debt reduction). Without explicit mechanisms, agile teams can become overly reactive and never invest in next-gen technology or architectural improvements, which is risky in a fast-evolving domain like automotive. Culturally, leadership should encourage teams to use the slack provided (by IP iterations or similar) truly for innovation – not just to catch up on backlog items. Some organizations have instituted something akin to Google’s “20% time” within their automotive R&D departments even as they run agile – giving engineers a slice of time to tinker and bring forward new ideas. This can directly feed into new requirements for future sprints. The research suggestion is to gather empirical evidence on how effective these approaches are, but intuitively, teams that feel they have permission to think beyond immediate tasks are more likely to come up with breakthrough features (e.g., think of on-team innovations like a clever fuel-saving algorithm or a new user convenience that wasn’t in the original plan but emerged from team creativity). In planning terms, agile at scale also needs to consider roadmapping: product management should still project a high-level roadmap of features over the next few quarters or years (common in automotive where a car model’s features might be mapped 3-5 years out). The agile difference is that the roadmap is not a fixed contract but an evolving vision that is revisited frequently. Keeping a balance between executing current sprint content and future roadmap refinement is a challenge – one that effective Product Owners and Product Managers must juggle.
Impact on infrastructure (6.d): This challenge often gets overlooked, but it’s crucial: going agile can strain existing development infrastructure. Automotive development relies on specific infrastructure like build servers, test benches, vehicle prototypes, continuous integration pipelines, and more. If teams now are delivering and integrating continuously, can the infrastructure handle it? Kasauli et al. mention establishing virtual test rigs and simulation models as one solution to ease infrastructure constraints. For example, instead of waiting for an expensive physical prototype car to test each new software increment, use a virtual vehicle simulator. This drastically reduces the wait time and cost, enabling more frequent integration. They also note that having feature teams and cross-functional teams helps because teams are less likely to be blocked waiting on another department’s infrastructure. In other words, if each team has some degree of self-sufficiency (their own test environment, their own hardware-in-loop setup), then work can progress in parallel. Some companies invested in duplicating certain test setups so that each agile train had a dedicated lab – a costly but effective way to reduce contention. The study also hints that awareness of critical requirement changes across the system is needed – which could be interpreted that when a certain requirement change might, for instance, require a new type of test or new equipment, the organization needs to know that quickly. For instance, if a new requirement is to use a different sensor that the old test rigs can’t simulate, that infrastructure gap needs addressing early. A DevOps mentality is creeping into automotive: continuous integration/delivery (CI/CD) for embedded automotive software is being established, which means robust build/test infrastructure (like nightly integration builds, automated drive simulations, etc.). Many companies find their legacy infrastructure (maybe geared for a build every few weeks) isn’t up to the task of CI/CD, and they must upgrade tools, invest in cloud simulation, containerize their software, etc. This is an organizational challenge because it requires budget and coordination to improve infrastructure – sometimes outside the scope of any one project’s backlog. One recommendation is to treat infrastructure improvements as first-class backlog items too (an example of enabler work), to ensure they get done. Another is fostering collaboration between IT departments and engineering – agile at scale often blurs the line, requiring IT to provide flexible environments for engineering (e.g., on-demand compute for simulations). An agile organization will encourage a culture where teams don’t say “oh, integration is someone else’s problem”; instead, teams and tool specialists work together to automate and streamline integration and testing. This cultural shift is part of the DevOps movement extended into automotive embedded systems.
On a broader cultural note, large automotive organizations face the challenge of change resistance. Agile introduces new roles (Scrum Master, Product Owner), changes responsibilities (project managers might need to evolve into agile leaders or release train engineers), and asks people to collaborate more across silos. Early in transformations, it’s common to encounter skepticism: “Cars can’t be developed like apps” or “We’ve always done it this way.” Addressing this requires strong management support and often some organizational restructuring. Many firms create agile champion teams or centers of excellence to train and coach teams. Others phase the transformation: starting with software teams, then integrating hardware teams once some success is shown. In the Kasauli study, one automotive company (Automotive 2) was noted as still having a V-model overall with agile software teams inside. This “island of agility” pattern is common – it eases the organization in. But it also creates tension as those agile teams bump against the old waterfall artifacts. Over time, if agile proves its worth (say, software is delivered faster, with fewer issues), the organization may expand agile practices to more areas. It’s a gradual process of building trust in the new way of working.
Summarizing the organizational challenges: automotive firms must align agile teams with traditional governance (or evolve governance to be agile-friendly), integrate continuous testing and validation into their process, ensure people have bandwidth for forward-looking innovation even amid rapid sprints, and upgrade their technical infrastructure to support frequent delivery. Culturally, they need to nurture an agile mindset beyond individual teams – bridging departmental divides and aligning everyone (from management to safety engineers to suppliers) with agile values of collaboration and adaptation. This is arguably the hardest part of scaling agile, as it involves changing entrenched structures and habits. But the payoff is huge: organizations that successfully transform report faster development cycles and higher productivity – McKinsey found top software companies (across industries) can have 3-6x higher throughput and quality than bottom performers, and many automotive players are striving to achieve those gains by updating their operating models and governance.
Before concluding with recommendations, let’s consider what gaps remain and future opportunities to further improve agile requirements engineering in automotive.
Despite the progress in adapting agile to large-scale automotive projects, there are still notable gaps where current practices and frameworks fall short, presenting opportunities for improvement, further research, or new tool development:
In summary, while current frameworks and company practices have addressed many initial hurdles of agile requirements engineering in automotive, there remain opportunities for improvement. By advancing tool support, integrating safety and regulatory needs, enhancing reuse and modeling approaches, developing better metrics and multi-organizational processes, and treating knowledge as a first-class asset, the industry can further reduce the gap between agile theory and practice in large-scale systems. Bridging these gaps will likely require collaboration between tool vendors, academia, and the industry, as well as continued cultural evolution within companies.
Large-scale agile development in the automotive industry brings significant requirements engineering challenges, but as we have discussed, these challenges are not insurmountable. By understanding and proactively addressing them, automotive organizations can harness agile’s benefits – faster delivery, increased adaptability, and improved customer focus – without sacrificing the rigor and alignment that complex automotive systems demand. Below, we conclude with key takeaways and actionable recommendations for requirements engineers, managers, and agile champions in automotive companies:
In conclusion, agile requirements engineering in automotive is a journey of blending agility with the robust practices of systems engineering. By focusing on customer value, embracing change in a controlled way, maintaining system overview (through documentation, models, and traceability), and evolving organizational structures and culture, automotive companies can overcome the challenges identified by Kasauli et al. and others. The result is an organization that is fast and flexible yet disciplined and aligned – able to deliver innovative automotive features to market quickly without compromising on quality, safety, or customer satisfaction. The path is certainly challenging, as it requires change at multiple levels, but the experience of early adopters like Volvo, BMW, and others shows that it is achievable and worth the effort. Agile methods, when adapted thoughtfully, are helping automotive engineering teams manage complexity and uncertainty better than ever before, ultimately shaping a future where vehicles are developed at the speed of software without steering off the road of rigorous engineering.
Duration: 2 weeks Cities: Christchurch, Hokitika, Kaikōura, Westport, Te Waipounamu, Nelson, Timaru Miles Travelled: 30 000Traveling through parts of New Zealand’s South Island offers a rich tapestry of history, landscape, and local character that leaves a quiet...
Background A global electronics manufacturer supplying critical components to the automotive and aerospace industries received multiple customer complaints regarding the premature failure of transistor-based power modules. Field analysis revealed that the root cause...
Background The quality department of a Tier-1 manufacturer in the automotive and aerospace sectors was expected to ensure strict compliance to both customer and regulatory standards. Instead, it became a bottleneck plagued by poor collaboration, low morale, and high...
Background ElectroTech, a manufacturer of electrical distribution components, including connector modules for power systems, received a major customer complaint regarding intermittent connection failures in one of its core electric product lines. The failures led to...
Duration: 3 days Cities: Singapore Miles Travelled: 6,300Visiting Singapore was like stepping into the future while still being surrounded by rich history and culture. From the moment I arrived at Changi Airport, with its indoor waterfalls and lush gardens, I knew...
Duration: 2 weeks Cities: Honolulu Miles Travelled: 7,000Our trip to Hawaii was truly a once-in-a-lifetime experience, filled with breathtaking landscapes, warm hospitality, and unforgettable moments. We stayed in Honolulu on the island of Oahu, where the vibrant mix...
Duration: 2 weeks Cities: Durham, Beamish Miles Travelled: 200Traveling to North East England offers a unique blend of history, culture, and character that stays with you long after you leave. One of the highlights is the enchanting city of Durham. Its cobbled streets...
Duration: 2 weeks Cities: Osaka, Tokyo, Hiroshima, Kyoto Miles Travelled: 9,000Japan in spring is pure magic. Spring felt like a moment suspended in time. The cherry blossoms were at their peak, casting a soft pink glow over temple roofs and narrow cobblestone lanes....
[dsm_gradient_text gradient_text="Implementing ISO 18404 in Your Organization: A Practical Guide" _builder_version="4.27.0" _module_preset="default" header_font="Questrial|||on|||||" header_text_align="center" header_letter_spacing="5px" filter_hue_rotate="100deg"...
[dsm_gradient_text gradient_text="Mastering ISO 18404: Essential Lean Six Sigma Competencies and Knowledge Areas" _builder_version="4.27.0" _module_preset="default" header_font="Questrial|||on|||||" header_text_align="center" header_letter_spacing="5px"...
[dsm_gradient_text gradient_text="The Future of Lean and Six Sigma: How ISO 18404 is Shaping the Industry" _builder_version="4.27.0" _module_preset="default" header_font="Questrial|||on|||||" header_text_align="center" header_letter_spacing="5px"...
[dsm_gradient_text gradient_text="ISO 18404 vs. Other Lean and Six Sigma Certifications: What's the Difference?" _builder_version="4.27.0" _module_preset="default" header_font="Questrial|||on|||||" header_text_align="center" header_letter_spacing="5px"...