Documentation practices in agile 5G network projects

The deployment of a private 5G network using srsRAN involves complex and iterative processes that benefit from agile project management practices. Agile methodologies, characterized by iterative development, flexibility, and continuous feedback, can greatly enhance the efficiency and effectiveness of such projects. However, these practices also pose unique challenges for documentation. Effective documentation is crucial in agile projects, as it ensures that all stakeholders are aligned and that knowledge is preserved throughout the development lifecycle. In the context of 5G network projects, where technical complexity and evolving requirements are prevalent, documentation must balance thoroughness with agility. It must be comprehensive enough to support technical development and integration but flexible enough to accommodate changes and updates as the project progresses. This paper explores the documentation practices employed in agile 5G network projects, specifically focusing on the experience of deploying a private 5G network using srsRAN. By examining the documentation approaches used in this context, we aim to identify best practices and propose improvements that can enhance project management and outcome. The insights gained from this research are intended to contribute to a better understanding of how documentation can be optimized in agile frameworks to support the successful deployment of private 5G networks.

1 Introduction

1.1 Background and context

The advent of 5G technology represents a transformative leap in wireless communication, promising enhanced performance, reduced latency, and increased capacity compared to its predecessors. While public 5G networks, operated by major telecommunications providers, offer widespread coverage and high-speed connectivity, private 5G networks provide an alternative that is tailored to the specific needs of organizations and industrial environments. These private networks offer significant advantages, including customized configurations, enhanced security, and dedicated resources, which are crucial for applications requiring stringent performance standards and data protection.

Private 5G networks are particularly beneficial for industries such as manufacturing, healthcare, and smart cities. In manufacturing, for instance, private 5G can enable real-time data processing and control for automation systems, enhancing operational efficiency and safety. Similarly, in healthcare, private 5G networks can support advanced telemedicine applications and remote monitoring, ensuring reliable and secure communication channels for critical health data. Smart cities can leverage private 5G to manage and integrate various urban systems, such as traffic management and environmental monitoring, with unprecedented efficiency.

1.2 The role of srsRAN

Central to the implementation of private 5G networks is the software that drives the radio access network (RAN). srsRAN (Software Radio Systems for Radio Access Networks) is an open-source software suite designed to facilitate the deployment of 4G LTE and 5G New Radio (NR) base stations. Its modular and flexible architecture enables organizations to build and customize their own radio access networks with a high degree of adaptability and cost-efficiency (SRS-LTE, 2024).

There have been a number of 5G Standalone (SA) open-source cellular platforms developed in recent years. These platforms provide an excellent opportunity for researchers to collaborate with the industry in advancing the standardization and optimization of 5G SA. Three prominent open-source 5G radio access network (RAN) projects are UERANSIM (GitHub - aligungr/UERANSIM), OpenAirInterface (OAI) (“OpenAirInterface), and srsRAN (SRS-LTE, 2024). Both srsRAN and OAI implement a subset of 3GPP Release 16, offering a complete version of the full protocol stack in accordance with 3GPP standards and specifications for 5G networks. In contrast, UERANSIM only includes Layer three radio protocols and does not implement Layer 1, such as PHY, and Layer 2, such as MAC, of the RAN protocol stack.

A significant difference between the srsRAN and OAI platforms lies in the sub-carrier bandwidth, number of channels, and support documentation. OAI offers greater flexibility in terms of sub-carrier bandwidth, allowing for lower latency and better support for higher-frequency bands at increased bandwidths. While srsRAN supports only SISO antenna designs, OAI supports both SISO and MIMO, thereby providing enhanced throughput under similar signal-to-noise-plus-interference conditions. Although OAI is superior in terms of its features, srsRAN offers better community support and documentation, making it easier to use (Mamushiane et al., 2023). Based on this information, we have chosen to use srsRAN, as also recommended by (Mamushiane et al., 2023) as a starting point for 5G network research.

srsRAN’s open-source nature provides several key benefits. It allows for extensive customization and innovation, making it possible to tailor the network to meet specific operational requirements. By eliminating the need for expensive proprietary software licenses, srsRAN also significantly reduces the cost of deploying and maintaining private 5G networks. Furthermore, its compatibility with various hardware components and integration capabilities makes it an ideal choice for organizations seeking to deploy private 5G solutions.

1.3 The importance of documentation

Effective documentation is crucial in the development and management of complex projects such as private 5G networks, as it underpins several key aspects of project success and continuity. Knowledge preservation is a primary benefit of comprehensive documentation, as it captures critical decisions, configurations, and design choices made throughout the project. This repository of knowledge is essential for future maintenance, troubleshooting, and upgrades, ensuring that critical information remains accessible and mitigating the risks associated with personnel changes or project transitions. Facilitating communication is another vital role of effective documentation; clear and thorough records provide a common reference point that aligns team understanding and expectations, thereby reducing the likelihood of misunderstandings and errors, which fosters smoother project execution and enhances stakeholder satisfaction. In addition, supporting compliance and auditability is crucial, especially in projects involving sensitive data or regulated industries. Accurate documentation ensures adherence to regulatory requirements and provides a transparent record for audits and reviews. Furthermore, enabling efficient troubleshooting and maintenance relies heavily on detailed documentation of network configurations, issues, and resolutions. Well-maintained records facilitate quicker issue identification and resolution, thus minimizing downtime and enhancing overall network reliability. Lastly, enhancing project continuity through documentation offers a historical record of the project’s development, decisions, and changes, which supports ongoing development efforts, helps new team members integrate swiftly, and ensures a well-documented evolution of the project. This multi-faceted importance underscores the critical role of documentation in achieving project success and long-term sustainability.

1.4 Problem statement

In the context of developing private 5G networks, particularly those using advanced technologies like srsRAN, effective documentation is a critical yet challenging aspect of project management. The complexity of 5G network development, coupled with the iterative and adaptive nature of agile practices, presents several unique challenges for documentation as summarized in Table 1, to concrete 5G/srsRAN manifestations, Table 2, reinforcing the relevance of the analysis. These challenges underscore the importance of developing effective documentation strategies to ensure project success.

Table 1

Table 1. Challenges of documentation in agile 5G network development.

Table 2

Table 2. Challenges of Documentation in Agile 5G Network Development with 5G/srsRAN-specific manifestations.

While agile practices prioritize flexibility and minimal documentation, the inherent complexity of private 5G network projects necessitates a more nuanced approach to documentation. Addressing these challenges effectively is crucial to achieving project success, ensuring seamless integration, and maintaining long-term operational efficiency.

1.5 Research objectives

The primary objectives of this research are: 1. To evaluate the documentation practices used in the deployment of a private 5G network with srsRAN. 2. To assess how these practices align with agile principles and identify any gaps or areas for improvement. and 3. To propose recommendations for optimizing documentation strategies in agile 5G network projects, aiming to enhance project efficiency and effectiveness.

By addressing these objectives, this study seeks to contribute valuable insights into the management of documentation within agile frameworks for complex network deployments, ultimately supporting more successful and streamlined 5G network projects.

2 Literature review

Agile methodologies have profoundly influenced both software and network development, offering enhanced flexibility, collaboration, and responsiveness. The foundational work by Beck et al. (2001) established the Agile Manifesto, which introduced key principles such as iterative development and customer collaboration that are now fundamental to agile practices in various fields (Bec et al., 2001). Highsmith and Cockburn (2001) further elaborated on these principles, emphasizing the adaptability and value delivery aspects of agile methodologies, which have proven essential in managing complex projects (Highsmith and Cockburn, 2001). Recent research has built upon these foundational concepts, exploring their application and evolution in modern contexts. For example, a study by Dingsøyr et al. (2012) provided insights into how agile methods address the unpredictable nature of software projects and improve team dynamics through iterative feedback (Dingsøyr et al., 2012). In the context of network development, Weber et al. Boehm and Turner’s (2003) discussion of balancing agile and traditional methods remains highly relevant, offering guidance on integrating agile practices with structured project management approaches (Boehm and Turner, 2003). Similarly, recent work by Poppendieck and Poppendieck (2003) has contributed to the understanding of how lean principles complement agile practices to enhance efficiency and reduce waste (Poppendieck and Poppendieck, 2003). On the other hand, Fitzgerald and Stol (2014) reviewed the adoption of agile practices across different contexts, including network development, and discussed the benefits and challenges associated with scaling these methodologies (Fitzgerald and Stol, 2014). Boehm and Turner (2004) offered a nuanced perspective on balancing agile and plan-driven methods, which remains relevant in understanding the interplay between different project management approaches (Boehm and Turner, 2004). In the telecommunications domain, the work in (Aydın et al., 2025) examined a large-scale agile transformation and found that although Scrum was central to the company’s process, a hybrid approach (combining agile with plan-driven elements) was crucial for balancing regulatory and business needs while ensuring continuous improvement and flexibility in network projects. Additionally, this work (Mishra et al., 2024) discussed how emerging 5G capabilities can bolster agile project management by enabling real-time data sharing and faster decision-making, thereby making agile methods even more effective and responsive in network deployment scenarios. Collectively, these studies underscore the enduring significance of agile principles and their ongoing evolution to meet the demands of modern software and network development.

While the aforementioned studies provide valuable insights into documentation and project management in general, our paper introduces a unique aspect and contribution that set it apart from the existing literature.

Specifically, in this work, we present a detailed case study on Open RAN documentation. We present real-world examples and case studies that illustrate how documentation practices can be optimized for different phases of Open RAN deployment, offering actionable insights for practitioners.

3 Methodology

The design of the case study in this paper is centered on examining the documentation practices during the deployment of a private 5G network using srsRAN. The case study is designed to provide an in-depth understanding of how agile project management principles impact documentation in a technically complex and evolving environment, such as 5G network deployment.

3.1 Case selection

The deployment of a private 5G network using srsRAN was chosen for the case study because.

$•$ Technical Complexity: 5G network projects, particularly using open-source tools like srsRAN, require significant technical detail and careful documentation to ensure integration, configuration, and performance.

$•$ Agile Environment: The project used agile methodologies, characterized by iterative development, flexibility, and continuous feedback, which is ideal for studying the balance between agility and thorough documentation.

$•$ Practical Relevance: As 5G networks are increasingly deployed in various industries, understanding documentation practices in such projects provides insights that can be applied in real-world scenarios.

3.2 Research focus and objectives

The primary focus of this case study is to.

$•$ Evaluate Documentation Practices: Examine the existing documentation approaches used during the deployment, particularly in relation to the agile methodology.

$•$ Assess the Balance between Agility and Thoroughness: Investigate how well the project managed to maintain the agility of the process while still ensuring sufficient technical documentation.

$•$ Identify Challenges and Improvements: Highlight any documentation-related challenges that emerged during the deployment and propose improvements or best practices that could enhance future 5G network projects.

3.3 Case study boundaries

To maintain a clear and focused scope, the case study is limited to the following boundaries.

$•$ Time Frame: The case study focuses on the deployment process from the initial setup phase to the operational state of the private 5G network.

$•$ Project Phases: The study examines documentation practices at various stages, including the design, installation, configuration, and testing of the 5G network.

$•$ Stakeholders: The study focuses on the project team involved in deploying the 5G network, but without conducting interviews. All data collection will be based on observations and documentation artifacts produced during the project.

$•$ Tools and Technologies: The case study will specifically investigate the deployment of a 5G network using srsRAN, an open-source software suite used for 4G/5G RAN (Radio Access Network) systems, to explore how such deployments handle the complexities of agile documentation.

3.4 Data collection methods

Data for this case study is collected primarily through direct observation and the analysis of project artifacts related to documentation. The following methods are employed.

$•$ Observations: Observations focus on the technical processes during the deployment, such as iterative development cycles, system integration, configuration steps, and testing. - Documentation practices are observed during each stage of the deployment process, specifically noting how documentation is created, updated, and managed across iterations. - The focus of the observations is on how the team balances documenting technical details with the need for rapid iterations and adaptability, as required by agile practices.

$•$ Artifact Analysis: The study analyzes a variety of documentation artifacts produced during the deployment, including configuration files, installation guides, logs, and testing reports. - The analysis looks at the content (thoroughness of technical detail), format (whether it supports easy updates), and usage (how the documentation is used by the team during development). - Version control systems (such as Git) are also reviewed to track changes made to documentation over time, observing how documentation evolves with the project.

3.5 Data analysis framework

The analysis of the collected data follows an iterative evaluation framework, aligned with agile principles. This framework includes.

$•$ Thematic Analysis: Key themes are identified from the observations and documentation, focusing on issues such as documentation completeness, agility in documentation, knowledge sharing, and documentation adaptability.

$•$ Comparative Analysis: Observations are compared against the agile principles to determine how well the project adhered to agile documentation strategies, such as the focus on “just enough” documentation while still maintaining necessary technical detail.

$•$ Challenge Identification: Specific challenges in maintaining documentation through iterations, changes, and evolving requirements are identified and analyzed to understand the root causes of these issues.

$•$ Best Practices Derivation: From the analysis, best practices are derived, offering strategies for balancing comprehensive documentation with the flexibility required by agile methodologies.

3.6 Evaluation criteria

The success of the documentation practices is evaluated based on the following criteria.

$•$ Alignment with Agile Principles: How well the documentation practices aligned with agile principles, such as maintaining flexibility and minimizing unnecessary documentation while ensuring clarity and comprehensiveness.

$•$ Efficiency: The extent to which the documentation supported the team’s ability to work efficiently, collaborate effectively, and quickly respond to changing requirements.

$•$ Technical Detail and Usability: Whether the documentation contained sufficient technical detail to be useful for integration and future reference, and whether it was easily maintainable and usable across different phases of the project.

$•$ Knowledge Preservation: How well the documentation helped preserve knowledge across different stages and transitions within the project.

3.7 Limitations of the case study

$•$ Lack of Interviews: The study relies solely on observations and artifacts without interviews from team members, which limits access to subjective insights, such as individual challenges or personal experiences with documentation.

$•$ Single Project Focus: Since this case study is limited to a single private 5G network deployment, the findings may not be entirely generalizable to other 5G projects or industries using agile methodologies, though lessons learned can still provide valuable insights.

In conclusion, the design of this case study provides a structured approach to investigating documentation practices in an agile project deploying a private 5G network. By focusing on observation and artifact analysis, the study aims to draw meaningful insights into how agile methodologies influence documentation in complex technical projects. This will lead to the identification of best practices and strategies for balancing agility with the thoroughness required for successful 5G network deployment.

4 Case study: private 5G network deployment with srsRAN

4.1 Project overview

This case study focuses on the deployment of a private 5G network utilizing srsRAN, an open-source software for 4G and 5G cellular networks. The primary objective of the project was to set up a functional 5G network for internal use, enabling the testing of advanced telecommunications concepts and technologies. The scope of the project included configuring the core network components 5G Core (Open5GS), deploying the gNB (srsRAN Project), and ensuring communication between the User Equipment (UE) and the network. The deployment leveraged agile project management methodologies to ensure flexibility, adaptability to evolving technical requirements, and continuous feedback loops for improvement. Figure 1 shows all the system components.

Figure 1

Figure 1. System’s architecture used in the case study. It shows the 5G network components along with the software used.

The srsRAN software was selected due to its flexibility and open-source nature, allowing the team to experiment with various configurations and adapt the network to their specific needs. Also, We selected the Open5GS software for its comprehensive, 3GPPcompliant 5G Standalone (5G-SA) core, which includes essential network functions like the AMF, SMF, UPF, and NRF. Its modular, open-source architecture facilitates containerization for rapid deployment with srsRAN, while an active community, thorough documentation, and standard interface support (N1/N2/N3) ensure seamless interoperability and long-term extensibility. The project aimed to balance rapid development cycles with the need for comprehensive technical documentation, ensuring future deployments could replicate the setup efficiently.

4.2 Agile practices in the deployment

Agile project management played a crucial role in the deployment process, facilitating iterative development and rapid adjustments to the evolving requirements of a complex 5G network. Key agile practices employed during the project included.

$•$ Iterative Development: The project was divided into small, manageable sprints, each focusing on specific components of the 5G network. For example, the first sprint involved installing and configuring the 5G Core (Open5GS), while subsequent sprints focused on the deployment of the gNB (srsRAN Project) and establishing connectivity with the User Equipment (UE). The deployment of each component followed a build-test-review cycle, ensuring that potential issues were addressed promptly.

$•$ Feedback Loops: Continuous feedback was a core part of the development process. After each sprint, the team conducted retrospectives to assess the network’s performance and the accuracy of the configuration. This iterative evaluation was essential to identify misconfigurations early, adapt to unexpected behaviors, and ensure that incremental changes were moving the project in the right direction. For instance, logs generated during gNB (srsRAN Project) startup were reviewed to verify proper communication with the 5G Core (Open5GS). These logs often revealed subtle issues such as timing mismatches or incorrect interface bindings that could affect service stability. Feedback loop modules were therefore necessary to systematically capture operational data, translate it into actionable insights, and inform the next cycle of configuration or architectural adjustments. For example, after identifying suboptimal transmission performance, the team used this loop to adjust gain settings and monitor their effect in subsequent iterations. In this way, the feedback loop not only supported continuous improvement but also enabled the network to evolve reliably under agile constraints.

$•$ Flexibility: The agile approach allowed rapid adaptation to changing requirements. As the project progressed, network settings such as frequency bands were adjusted to accommodate hardware limitations and performance needs. Agile practices helped maintain momentum without delaying the overall project timeline.

To clarify how our agile process mapped onto the different components of the 5G system, we introduce Figure 2, a Sprint-Layer Timeline that charts each 2-week sprint against the UE, gNB, or Core activities.

Figure 2

Figure 2. Each 2-week sprint plotted against the network layer primarily addressed—UE, gNB, 5G Core, or cross-layer integration.

4.3 Documentation practices

4.3.1 Initial approach

At the beginning of the project, the documentation strategy focused on creating detailed guides for each installation and configuration step. The initial goal was to ensure that every team member could follow a standardized set of instructions for tasks such as installing srsRAN and configuring the network interfaces. As part of this strategy, installation guides were created for both the gNB (srsRAN Project) and the 5G Core (Open5GS). For example, the guide for setting up the gNB (srsRAN Project) outlined every step, from installing dependencies to configuring radio parameters and network interfaces as shown in Configuration File captured in Figure 3. Similarly, Installation Guide two covered the 5G Core (Open5GS) setup.

Figure 3

Figure 3. gNB Configuration File 1 (YAML). Highlights the ru_sdr block (device driver, sample rate, TX/RX gains), the cell_cfg section (DL ARFCN, channel bandwidth, subcarrier spacing), and the metrics section enabling JSON reporting.

Configuration files, such as those used to configure NGAP and GTP tunnels, were thoroughly documented (see Configuration File 1), ensuring clarity on critical parameters like IP addresses, PLMN IDs, and frequencies. However, this detailed documentation approach initially struggled to keep pace with the rapidly evolving network configurations and requirements.

4.3.2 Documentation during iterations

As the project advanced through successive sprints, the documentation approach evolved to align with the iterative development process. Instead of trying to maintain exhaustive documentation for each component upfront, the team adopted a more flexible and dynamic strategy.

$•$ Live Documentation Updates: After each sprint, the configuration files and installation guides were revised to reflect any changes made during the iteration. This ensured that the documentation remained up-to-date and aligned with the actual deployment. For example, logs generated during a specific iteration as the log file shown in Figure 4.

$•$ Balancing Detail with Agility: To avoid slowing down development, documentation was streamlined to focus on critical elements that were most likely to change, such as network interface configurations and UE connection parameters. More static elements of the setup, such as dependency installation, remained detailed but required less frequent updates.

Figure 4

Figure 4. Log File 1: AMF of 5G Core Startup Log. It shows SBI interface events: endpoint setup at [127.0.0.10:7777], followed by NRF-notify subscription and profile update messages. The timestamps and handler callbacks verify successful control-plane integration during initialization.

4.4 Challenges encountered

Several challenges were encountered when trying to balance thorough documentation with the agility required by the iterative deployment process.

$•$ Technical Complexity: Configuring a private 5G network involves numerous interconnected components, including the gNB (srsRAN Project), 5G Core (Open5GS), and User Equipment. Managing parameters like PLMN ID, NGAP setup, and GTP tunnels made it difficult to keep the documentation concise yet informative. Additionally, ensuring that all technical details were correctly captured without overwhelming the development process was a significant challenge.

$•$ Changing Requirements: As the project progressed, the need to adjust network parameters such as IP addresses and gain settings arose frequently. For example, changes to the gNB (srsRAN Project)’s tx_gain settings (see Configuration File in Figure 3) necessitated updates in both the configuration files and the corresponding documentation.

$•$ Evolving Standards: The 5G standards and best practices for network configuration are continuously evolving. As new features and functionalities were integrated into the network, it became increasingly difficult to ensure that the documentation reflected the latest industry standards without delaying development.

4.5 Observations

The following observations were made regarding documentation practices during the deployment.

$•$ Strengths: The agile approach to documentation allowed the team to quickly adapt to changing requirements without being bogged down by exhaustive, static documentation. Live documentation updates ensured that each iteration had a corresponding, up-to-date configuration guide and log that could be referenced by the team.

$•$ Weaknesses: Balancing the level of detail with agility remained a challenge. At times, important technical details were overlooked in the rush to complete development cycles, leading to confusion during later stages. The iterative nature of the project resulted in fragmented documentation across different sprints, making it difficult to trace the full history of configuration changes. In one illustrative case, tracing the full history of the $t{x}_{\mathit{gain}}$ parameter required accessing four different files across three sprint folders: a YAML configuration file, two developer logs, and a commit message. On average, retrieving the history of a frequently updated parameter (e.g., PLMN ID, frequency band) involved consulting between three and five files dispersed across different sprint iterations. This level of fragmentation not only delayed troubleshooting but also emphasized the need for a centralized documentation repository or an indexed changelog to improve traceability.

Additional observations and Illustrative Incidents. Beyond the high-level strengths and weaknesses, three recurring patterns were observed.

$•$ Process-Level Drift: As sprint velocity increased, documentation tasks were routinely postponed to the end of the sprint, compressing the time available to capture changes accurately. This led to “last-minute” write-ups that omitted rationale behind certain configuration tweaks.

$•$ Artifact Fragmentation: Configuration files, logs, and installation notes were stored across multiple personal repositories and sprint folders. For instance, the PLMN ID change during Sprint three was documented in a commit message but not reflected in the shared configuration guide, delaying UE attachment troubleshooting.

$•$ Knowledge Bottlenecks: A small subset of team members authored or reviewed most documentation artifacts. When they were unavailable, others hesitated to modify documents, fearing inconsistencies—suggesting the need for clearer ownership rules and lightweight contribution guidelines. These observations indicate that agile speed, if not counterbalanced by explicit documentation checkpoints and roles, can systematically erode traceability and shared understanding in technically dense projects.

In conclusion, while the agile approach to documentation provided flexibility and adaptability, the project could have benefited from more structured guidelines on the necessary level of detail at each stage. Clearer standards on when and how to update documentation during sprints might have helped streamline the process further.

5 Analysis and findings

The deployment of the private 5G network using srsRAN yielded several significant results in terms of network performance and the effectiveness of the documentation practices employed throughout the project. This section discusses the key outcomes of the deployment, analyzes the documentation strategies used, and highlights areas for improvement.

5.1 Network performance results

The 5G network was successfully deployed, with key performance metrics recorded over the course of the project. The following table summarizes the results obtained from the network tests, including metrics for latency, throughput, and successful UE (User Equipment) connections.

As shown in Table 3, the observed values for network performance were close to the target values, with only minor deviations. We selected these six metrics to cover the three primary 5G service categories and overall system reliability.

$•$ Latency and packet loss rate characterize URLLC (Ultra-Reliable Low-Latency Communications), ensuring critical applications meet stringent delay and reliability requirements.

$•$ Downlink and uplink throughput capture eMBB (enhanced Mobile Broadband) performance, reflecting the system’s capacity to support high-bandwidth services.

$•$ Number of UEs connected represents mMTC (massive Machine-Type Communications), indicating network scalability and support for multiple devices.

$•$ Call setup success rate assesses overall signaling robustness and user experience quality.

Table 3

Table 3. Performance metrics for 5G network deployment.

The latency of the network remained well within acceptable limits for a private 5G deployment, and both downlink and uplink throughput exceeded the minimum required values. While the number of UEs connected was slightly below the target—primarily due to temporary hardware constraints—the call setup success and packet loss rates demonstrated reliable session establishment and packet delivery.

5.2 Documentation effectiveness

The agile documentation practices used during the project were evaluated based on how well they supported the deployment process. The documentation strategy was designed to balance the need for thoroughness with the agility required to adapt to the evolving network requirements.

5.3 Strengths

$•$ Real-Time Updates: The documentation was updated after each sprint, ensuring that the team had access to the latest configuration files and installation guides. This minimized confusion and improved the consistency of the deployment across different stages.

$•$ Flexibility: The documentation evolved dynamically with the project, reflecting the iterative changes made to the network configuration. This adaptability helped the team respond quickly to issues such as changes in frequency settings and adjustments to transmission power (as shown in Figure 3).

$•$ Reduced Redundancy: By focusing on critical configuration changes and minimizing redundant documentation, the team was able to maintain a balance between comprehensive detail and speed of execution.

5.4 Weaknesses

$•$ Inconsistent Level of Detail: One of the primary challenges was maintaining a consistent level of detail across all iterations. Early-stage documentation was highly detailed, but as the project progressed, some updates were brief, which led to gaps in the understanding of certain technical details. This was particularly evident in later sprints when changes in network parameters were not always thoroughly documented.

$•$ Fragmentation Across Iterations: Since the documentation was updated iteratively, it was sometimes fragmented across multiple sprints, making it difficult to trace the full history of configuration changes. A more centralized documentation approach might have mitigated this issue.

5.4.1 Fragmentation across sprints

During Sprints 1-4 each developer consulted an average of 11.8 files (6.4 configuration files, 3.1 installation guides, 2.3 log summaries) to execute a single network-parameter change. Table 4 details the dispersion ratio—the number of distinct documentation artefacts touched per sprint divided by the number of unique work-items. A ratio >1 indicates fragmentation.

$•$ Observed challenges Engineers reported (i) search overhead—up to 18 min to locate the correct version of a PLMN-ID file, (ii) context switching between repos causing mis-references, and (iii) merge conflicts when log excerpts were added to divergent guides.

$•$ Degree of agility Update-latency (UL) declined from 3.7 to 0.9 days across the four sprints (see Table 3), and traceability coverage (TC) rose from 0.42 to 0.79, indicating that documentation kept pace with sprint cadence while fragmentation steadily diminished.

Table 4

Table 4. Dispersion of documentation artefacts per work-item across sprints.

5.5 Analysis of documentation practices

The agile documentation strategy allowed for rapid updates and flexibility, but it also introduced challenges related to the consistency and thoroughness of the documentation. Early in the project, the documentation approach was comprehensive, with detailed guides and configuration files (as seen in the initial configuration file for the gNB (srsRAN Project)). However, as the project progressed and the complexity of the network increased, the documentation became more difficult to maintain at the same level of detail.

Further analysis revealed that the decline in documentation consistency was largely due to time constraints and the absence of sprint-specific documentation standards. For example, during the third sprint, a change to the PLMN ID was made but not recorded in the configuration history, causing a delay in subsequent UE connectivity. This highlighted the need for a centralized update protocol. Additionally, the documentation fragmentation mirrored a common agile trade-off as development accelerated, emphasis on “working software” led to deprioritization of non-critical documentation. These patterns suggest that without deliberate documentation checkpoints and defined ownership, even experienced agile teams may under-document critical steps in complex network environments.

Key lessons learned from the documentation practices include.

$•$ Agility vs. Completeness: While agile documentation practices allowed the team to move quickly and adapt to changes, there was a trade-off in terms of the completeness of the documentation. Future projects should establish clearer guidelines on the minimum level of detail required during each iteration to avoid gaps in knowledge transfer.

$•$ Centralized Documentation: To avoid the fragmentation observed during the project, a more centralized and version-controlled documentation system could be implemented. This would ensure that all updates and changes are tracked in a single location, providing a clearer overview of the project’s evolution.

$•$ Continuous Review: Regular reviews of the documentation at the end of each sprint can help maintain quality and consistency. This process could have identified missing details earlier, allowing for timely corrections.

5.6 Challenges and future improvements

Although the project was successful in deploying a functioning 5G network, there were challenges related to both network configuration and documentation.

5.6.1 Challenges

$•$ Traceability of Changes: Frequent parameter updates (e.g., frequency bands, NGAP settings) were not consistently versioned, making it hard to reconstruct the exact network state at any given time.

$•$ Tooling Misalignment: Teams used different tools (plain text docs, spreadsheets, Git commits) without a unifying convention, increasing search time and duplicate effort.

$•$ Time Pressure vs Thoroughness: Sprint goals prioritized functional milestones. Documentation tasks without immediate user impact were deprioritized, creating gaps that reappeared as technical debt.

$•$ Limited Stakeholder Feedback: Without interviews or structured feedback loops, subjective pain points (e.g., how readable or discoverable docs were) remained underexplored.

5.6.2 Future improvements and research directions

$•$ Documentation Ownership Matrix: Define who updates which artifact each sprint and what “minimum viable detail” must be captured (parameters changed, rationale, date).

$•$ Single Source of Truth (SSOT): Adopt a version-controlled, searchable platform (e.g., Git-backed wiki) where all artifacts live, with mandatory links from commits to docs.

$•$ Automated Capture Pipelines: Scripts that export running configs, diff them, and auto-append changes to a change-log would reduce manual effort and omission risk.

$•$ Quality Gates in Sprint Reviews: Add a documentation checklist to the “Definition of Done” so every sprint ends with verified, up-to-date artifacts.

$•$ Quantitative Doc Metrics: Measure documentation latency, completeness scores, or retrieval times to assess improvement rigorously.

$•$ Broader Validation: Replicate this study across multiple 5G projects or include interviews/surveys to generalize findings and capture human factors.

$•$ Security/Compliance Angle: Explore how documentation intersects with regulatory or security audits in private 5G deployments, a gap not covered here.

The technical complexity of the project, combined with the evolving nature of the requirements, made it difficult to document every change in real-time. Future projects would benefit from a more structured approach to balancing the need for rapid iteration with the requirement for comprehensive documentation.

In summary, the agile documentation practices used in this project were effective in ensuring that the team could keep pace with the evolving requirements. However, improvements in consistency, centralization, and review processes would further enhance the effectiveness of the documentation in future 5G network deployments.

6 Recommendations and best practices

Based on the observations and analysis of the documentation practices employed during the deployment of the private 5G network using srsRAN, the following recommendations and best practices are proposed. These practices aim to enhance both the efficiency of future agile 5G projects and the quality of the documentation to ensure that critical technical and operational knowledge is effectively captured and communicated.

6.1 Adopt a centralized documentation platform

One of the key challenges encountered in this project was the fragmentation of documentation across multiple iterations. To address this issue, it is recommended that future projects adopt a centralized documentation platform that supports version control. Platforms such as Git, Confluence, or specialized tools for agile environments can allow teams to.

$•$ Track changes to configuration files, network parameters, and installation guides in a single, unified repository.

$•$ Ensure that documentation updates are synchronized across teams and accessible in real-time.

$•$ Maintain a full history of documentation changes, making it easier to audit past decisions and trace the evolution of technical specifications.

This approach will reduce the risk of knowledge silos and ensure that all stakeholders have access to the most up-to-date information.

6.2 Define documentation standards for iterative projects

While agile projects often prioritize minimal documentation, there is a need for clear guidelines on the minimum level of detail required to avoid gaps in knowledge. For complex projects like 5G deployments, it is important to establish a standardized documentation framework that provides guidance on.

$•$ What must be documented during each sprint (e.g., configuration changes, network parameters, installation steps).

$•$ The level of detail required for configuration files, log files, and system architecture updates.

$•$ How to handle evolving requirements and changing configurations without creating redundancy or confusion.

Establishing these standards early in the project can help ensure that critical information is not lost, even in the fast-paced, iterative development cycle of agile projects.

6.3 Implement regular documentation reviews

Agile projects often move quickly, and documentation can become outdated if it is not reviewed regularly. To prevent this, it is recommended to implement scheduled documentation reviews at the end of each sprint. During these reviews.

$•$ Project teams should verify that all key updates, changes, and decisions have been documented properly.

$•$ Missing or incomplete documentation can be identified and corrected before the next iteration begins.

$•$ Teams can ensure that the documentation reflects the most current state of the network configuration, preventing discrepancies between documentation and the actual system setup.

Regular reviews will help maintain the consistency and accuracy of the documentation, particularly in fast-evolving environments like 5G network deployments.

6.4 Leverage automation for documentation generation

Given the technical complexity of 5G network projects, automating parts of the documentation process can reduce the time burden on the development team while ensuring accuracy. For example,.

$•$ Automated scripts can generate configuration files or extract key log data, reducing the risk of human error in documenting network parameters.

$•$ Version-controlled systems can automatically track changes to configuration files, avoiding the need for manual updates.

$•$ Documentation tools can be integrated with agile project management platforms, ensuring that documentation is automatically updated as part of the development workflow.

By leveraging automation, teams can streamline documentation efforts and maintain higher levels of accuracy, even in fast-paced development cycles.

6.5 Balance Agility and Thoroughness in documentation

One of the key challenges in this project was balancing the agility required for iterative development with the need for comprehensive documentation. It is recommended that future projects adopt a tiered documentation approach, where.

$•$ Critical elements, such as configuration files and installation guides, are updated with high levels of detail to ensure the accuracy of the deployment.

$•$ Non-critical or auxiliary documentation is kept lightweight to avoid unnecessary overhead, but with enough detail to support the project if the need arises.

$•$ Teams should consider a hybrid approach, where more detailed documentation is created for major milestones or significant technical changes, while minor updates follow a more agile, lightweight format.

This balanced approach will allow teams to remain flexible while ensuring that key technical information is well-documented.

6.6 Improve communication and collaboration among teams

In large projects like 5G network deployments, where multiple teams may be working on different aspects of the network, effective communication is crucial. To facilitate better documentation practices.

$•$ Teams should use collaborative tools that allow for real-time updates to documentation, ensuring that all members are aligned on key decisions and changes.

$•$ Cross-team collaboration should be encouraged, with shared access to documentation resources, configuration files, and deployment logs.

$•$ Clear roles and responsibilities should be assigned for maintaining and updating different parts of the documentation, ensuring accountability and consistency.

Enhancing collaboration and communication can reduce the risk of fragmented or incomplete documentation and ensure that all stakeholders are working from the same information base.

6.7 Train teams on agile documentation practices

While training is essential in any complex project, this study proposes it toward the end of the documentation improvement process rather than at the outset. This decision was based on the iterative nature of agile projects and the evolving documentation practices observed throughout the case study. Early in the deployment, documentation strategies and tools were still being shaped by the needs and challenges that emerged across sprints. As a result, conducting upfront training might have been premature, potentially leading to misalignment between training content and actual practices. By deferring training until the end, the program can incorporate lessons learned, use finalized tools and templates, and deliver highly relevant, experience-informed guidance that reflects the real documentation environment of the project.

Indeed, it is important to provide team members with proper training on agile documentation practices. Agile frameworks often emphasize minimal documentation, but for complex projects, it is critical that teams understand how to.

$•$ Identify what needs to be documented and what can be minimized.

$•$ Use the tools and platforms available to manage and update documentation efficiently.

$•$ Adapt documentation practices to the evolving requirements of the project, ensuring that critical technical and operational details are always captured.

Training team members on these topics helps them contribute to documentation efficiently while keeping the agile development cycle running smoothly.

6.8 Summary of recommendations

The recommendations outlined above aim to improve the effectiveness of documentation practices in future 5G network deployments. By adopting a centralized documentation platform, defining clear standards, conducting regular reviews, leveraging automation, and balancing agility with thoroughness, teams can ensure that they maintain high-quality documentation without sacrificing the flexibility required for agile development.

$•$ Centralize documentation using platforms with version control.

$•$ Define minimum documentation standards and update requirements.

$•$ Implement regular sprint-end documentation reviews.

$•$ Automate parts of the documentation process.

$•$ Balance the need for agility with thorough documentation of critical elements.

$•$ Encourage communication and collaboration among teams.

$•$ Provide training on agile documentation practices.

7 Conclusion

The deployment of a private 5G network using srsRAN within an agile framework highlighted the critical importance of effective documentation practices in ensuring project success. While agile methodologies provide the flexibility needed for iterative development, they also pose challenges in maintaining comprehensive and up-to-date documentation. This study demonstrated that balancing agility with thoroughness in documentation is essential, especially for complex technical projects like 5G networks.

The recommendations provided, including the adoption of centralized documentation platforms, regular reviews, and leveraging automation, offer practical strategies for overcoming these challenges. By implementing these best practices, future projects can improve the quality and efficiency of both their development processes and documentation, contributing to more successful and sustainable 5G network deployments.

8 Author summary

Deploying private 5G networks with tools like srsRAN involves intricate, evolving processes that can benefit significantly from agile project management. Agile methodologies, which emphasize flexibility, iterative progress, and continuous feedback, offer an efficient approach to managing the dynamic nature of these projects. However, the application of agile principles introduces specific challenges in maintaining effective documentation.

In agile projects, especially those dealing with the complexity of 5G networks, documentation serves as a critical tool for aligning stakeholders and preserving essential knowledge throughout the project lifecycle. The challenge lies in balancing the need for detailed technical records with the flexibility required to adapt to changes. This research focuses on the documentation strategies employed during the deployment of a private 5G network using srsRAN, identifying best practices that can improve both project management and technical outcomes.

Through this exploration, we aim to enhance understanding of how documentation can be optimized within agile frameworks to support the successful and adaptive deployment of private 5G networks. The findings from this study provide valuable insights into improving documentation processes in similar future projects.

Data availability statement

The original contributions presented in the study are included in the article/supplementary material, further inquiries can be directed to the corresponding author.

Author contributions

LA: Writing – review and editing, Writing – original draft. IA: Writing – review and editing, Writing – original draft. HA: Writing – review and editing, Writing – original draft.

Funding

The author(s) declare that no financial support was received for the research and/or publication of this article.

Conflict of interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Generative AI statement

The author(s) declare that Generative AI was used in the creation of this manuscript. They used generative AI tools to enhance the clarity, coherence, and overall quality of the writing in this paper. These tools were utilized to support language refinement and organization, while all research content, analysis, and conclusions are the original work of the author.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

References

Aydın, B., Tripathi, S., Samoylenko, S., and Tokgöz, N. (2025). Analysis of hybrid agile project management in the telecommunications industry. isletme Bilimi Dergisi J. Bus. Sci. 13 (1), 1–19. doi:10.22139/jobs.1576663

CrossRef Full Text | Google Scholar

Beck, K., et al. (2001). Manifesto for agile. Softw. Dev.

Google Scholar

Boehm, B. W., and Turner, R. J. (2003). Balancing agility and discipline: a guide for the Perplexed. IEEE Softw. 20 (1), 14–19.

Google Scholar

Boehm, B. W., and Turner, R. J. (2004). Using risk to balance agile and plan-driven methods. IEEE Comput. 37 (5), 52–60.

Google Scholar

Dingsøyr, T., Nerur, S., Balijepally, V., and Moe, N. B. (2012). A decade of agile methodologies: towards Explaining agile software development. J. Syst. Softw. 85 (6), 1213–1221. doi:10.1016/j.jss.2012.02.033

CrossRef Full Text | Google Scholar

Fitzgerald, B., and Stol, K.-J. (2014). Continuous software engineering and beyond: trends and challenges. Proc. 1st Int. Workshop rapid continuous Softw. Eng. 23 (4), 1–9. doi:10.1145/2593812.2593813

CrossRef Full Text | Google Scholar

GitHub - aligungr/UERANSIM (2015). Open source 5G UE and RAN (gNodeB) implementation. Available online at: https://github.com/aligungr/UERANSIM.

Google Scholar

Highsmith, J., and Cockburn, A. (2001). Agile software development: the business of innovation. Computer 34 (9), 120–127. doi:10.1109/2.947100

CrossRef Full Text | Google Scholar

Mamushiane, L., Lysko, A., Kobo, H., and Mwangama, J. (2023). Deploying a stable 5G SA Testbed using srsRAN and Open5GS: UE integration and troubleshooting towards network Slicing. Institute of Electrical and Electronics Engineers IEEE, 1–10. doi:10.1109/icabcd59051.2023.10220512

CrossRef Full Text | Google Scholar

Mishra, M. K., Selvaraj, K., Santosh, K., Aarif, M., Mary, S. C., and Bala, B. K. (2024). “The impact of 5G technology on agile project management: a cross-industry analysis,” in Proceedings of the 5th International Conference on Intelligent communication technologies and Virtual Mobile networks (ICICV), 210–218.

Google Scholar

Poppendieck, M., and Poppendieck, T. (2003). Lean software development: an agile Toolkit. Addison-Wesley.

Google Scholar

SRS-LTE (2024). SRS-LTE open-source 4G/5G software radio suite. Available online at: https://www.srslte.com/.

Google Scholar

OpenAirInterface (2024). 5G software alliance for democratising wireless innovation. Available online at: https://openairinterface.org/.

Google Scholar