Process Mining Reveals Hidden Delays in Farm Software Development

Farm management information systems have quietly become the digital backbone of modern agriculture, helping growers juggle everything from crop planning and machinery management to finance, quality assurance and traceability. Yet the companies that build these systems face a persistent challenge: agriculture is dynamic, farmers demand constantly evolving functionality, and vendors must deliver high-quality software updates quickly without sacrificing robustness. A new case study now shows that a technique borrowed from business process management, known as process mining, can expose exactly where development time is being lost in the creation of farm software, and the results are striking.

Researchers conducted an in-depth case study at a medium-sized farm management information system provider serving the horticulture industry, a company of roughly 120 employees that builds horticultural software on an enterprise resource planning platform extended through customizable modules, mobile applications and analytics tools. The study, which the authors describe as the first empirical investigation of process mining in farm management information system software development, combined quantitative analysis of event logs with qualitative interviews to answer three questions: how the agile development processes are actually carried out, which bottlenecks exist within them, and what causes those bottlenecks, particularly long cycle times.

Process mining works by extracting event logs from digital systems, in this case the company’s DevOps platform, where every task is automatically created after a project’s design phase and timestamped when it moves to in progress or done. These logs capture sequences of events tied to individual work items, allowing researchers to reconstruct how software development actually unfolds rather than how it is supposed to unfold on paper. The technique, described by its originator as a bridge between process science and data science, integrates business process management, optimization and analytics to uncover inefficiencies such as loops, rework and waiting times.

The researchers collected data spanning March 2020 to January 2025, then filtered it to include only product backlog items that began in 2023, the year the company’s software development process changed. After cleaning, imputation of missing timestamps with median values, and removal of outliers below ten minutes and above sixty days, the final event log contained 376 product backlog items and 2,110 tasks. The team also split the data around a key date, 15 March 2024, when the company implemented a strategy of reducing project sizes to improve development efficiency, and separated customer-driven collaborative development projects from internal maintenance and innovation work.

The control flow analysis revealed a substantial gap between the documented process and reality. Only 49 percent of product backlog items started as intended with the functional design step, with development and testing frequently serving as incorrect starting points, often because similar features allowed designs to be reused. The fitness of the desired process model to the actual event log was just 38 percent, indicating most cases were not processed exactly as expected. After correcting for data anomalies, the researchers mined a refined model with an inductive miner that achieved an average precision of 81.1 percent and a fitness of 74.9 percent. This model exposed unexpected parallelism, with technical design running alongside estimation and development alongside code review, as well as frequent loops, most notably 171 instances in the test step alone. In total, 270 different process variants were discovered, underscoring how heterogeneous real-world agile development can be.

The performance analysis produced the study’s most eye-catching number: of the median 79 days a typical development item took to complete, only 22 days involved active work. The remaining 57 days consisted of waiting time, meaning roughly 72 percent of the total cycle time was spent inactive. Flow efficiency at the company was low compared with benchmarks from earlier software engineering research, highlighting considerable opportunity for improvement by reducing delays at handover, estimation and rework stages. Over time, cycle times did fall from 109 to 79 days, and approximately 80 percent of that reduction could be attributed to lower waiting times, suggesting the project-size reduction strategy was effective.

At the level of individual process steps, code review emerged as the most critical bottleneck, showing the highest median process step duration at 16.9 days and a growing impact over the study period, driven by increases in both processing and waiting times. This finding surprised the company, since code reviews are expected to require limited effort, and interviews suggested the bottleneck correlated with delays in task completion and administration rather than the review activity itself. Automatically triggered DevOps tasks were not always followed up promptly, were often not closed when completed, and task statuses were unreliable, undermining sprint planning accuracy. Estimation and development followed as secondary bottlenecks, with estimation characterized by extremely low flow efficiency due to excessive waiting.

Comparing project types added further nuance. Customer-driven collaborative development projects achieved substantially shorter cycle times than internal projects, 48 versus 85 days, reflecting lower processing and waiting times throughout. However, technical design and development remained important bottlenecks in these customer projects, reflecting the complexity of translating customer-specific requirements into a standardized software product. The researchers also compared product backlog items with short cycle times, under 90 days, against those with long cycle times of 90 days or more, and identified three main drivers of the delays: batching of design tasks, prioritization of customer projects at the expense of internal work, and limited testing capacity, exemplified by one team with a single tester who also served as Scrum master. Notably, after the project split in March 2024, batching in functional design ceased and its median processing time plummeted from 31.3 to 0.9 days.

The qualitative interviews added context invisible in the event logs. Developers reported that ambiguities in largely text-based design documents forced time-consuming clarifications that sometimes triggered design revisions. Testing was described as highly manual, with tailored test cases often skipped initially due to time constraints in favor of predefined scenarios, which increased testing effort later and contributed to rework. Reproducing bugs depended on clear test setups, and verifying fixes manually added further workload. Communication challenges were compounded by globally distributed teams, where time zone differences limited real-time collaboration and reliance on online meetings made resolving uncertainties slower than in-person discussion would allow.

The authors caution that the findings come with limitations. The process data contained missing and inconsistent information requiring cleaning, imputation and assumptions, and the observed relationships should not be interpreted as strictly causal, since multiple organizational changes occurred during the study period. The single-company case study design also limits generalizability, and some analyses relied on relatively small subsets of data. Nevertheless, the study demonstrates that process mining, when integrated with qualitative insights from practitioners, is a powerful tool for diagnosing and improving agile software development in the agricultural domain. Faster delivery of new functionalities can help keep farm management systems aligned with the needs of farmers and growers, supporting adoption and long-term value, though the researchers note that speed gains came with increased process loops, indicating a trade-off between time efficiency and process quality that organizations must manage carefully. They suggest future work should repeat such studies with larger datasets and in other farm software companies, and position process mining not as an end in itself but as a key building block in a broader cycle of continuously discovering, analyzing and improving business processes.

Subject of Research: Application of process mining to identify bottlenecks in agile software development for farm management information systems

Article Title: Process mining for agile development of farm management information systems

Article References: Babur, Ö., Frisch, M., & Verdouw, C. (2026). Process mining for agile development of farm management information systems. Smart Agricultural Technology, 15, Article 102653. https://doi.org/10.1016/j.atech.2026.102653

Image Credits: AI Generated

DOI: 10.1016/j.atech.2026.102653

Keywords: process mining, farm management information systems, agile software development, horticulture, event logs, cycle time, waiting time, code review bottleneck, case study, business process management, DevOps, agricultural software