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

The research, conducted by Matthias Mayer and Matthias Althoff of the TUM School of Computation, Information and Technology, tackles what roboticists call base-pose optimization. A robot’s base pose is its position and orientation on the factory floor, and it determines which points in the workspace the arm can comfortably reach, how contorted its joints must become to hit each target, and how long every cycle of the production process takes. Moving the base by even a few tens of centimeters can shave seconds off a cycle time, and over millions of cycles those seconds translate into substantial money. Crucially, unlike buying a faster robot, repositioning the one you already have costs essentially nothing.

Despite decades of interest, the field had never established which optimization algorithm actually performs best. Previous studies each championed their own method on their own tasks, with no common benchmark to arbitrate between them. Mayer and Althoff set out to close this gap by implementing four families of optimizers on identical footing: exhaustive search approximated by uniform random sampling, genetic algorithms, Bayesian optimization, and, for the first time in this domain, stochastic gradient descent. They adapted Adam, the optimizer that underpins much of modern neural network training, to the robot placement problem, requiring only that the robot’s forward kinematics be well defined rather than any special wrist geometry assumed by earlier gradient-based work.

The technical setup is a two-level optimization. At the outer level, the chosen algorithm proposes candidate base poses within an allowed region, roughly a cubic meter around a nominal position with either fixed or unrestricted orientation. At the inner level, a task solver evaluates each proposal. Fast filters first reject poses farther from any goal than the robot’s maximum reach, a check that takes milliseconds, then reject poses lacking collision-free inverse kinematic solutions, which takes about a tenth of a second. Surviving candidates go to the RRT-Connect path planner and a time-optimal trajectory generator, which produce an executable motion through all required goal poses. The cycle time of that motion becomes the cost. For gradient descent, the researchers used automatic differentiation in PyTorch to compute how the cost changes with the base parameters, then applied Adam steps, restarting from random initial guesses to escape local minima.

The benchmark tasks came from CoBRA, a composable benchmark suite for robotics applications. The team built a set of 100 simple synthetic tasks with three cubic obstacles and three goal poses, then tested generalization on harder variants with five goals and obstacles, on tasks derived from 3D scans of real factories where robots feed CNC machines amid irregular geometry, and on deliberately perverse edge cases where all goals sit tightly against obstacles. Hyperparameters for the three tunable methods were optimized with Optuna using a tree-structured Parzen estimator, trained on the first 70 percent of the simple tasks and evaluated on the remainder plus the unseen sets. Every algorithm received an identical budget of 20 minutes per task, and results were aggregated over five random seeds with 95 percent confidence intervals and Wilcoxon signed-rank tests.

The headline finding is that stochastic gradient descent wins on reliability. Across all tasks, SGD achieved a significantly higher success rate than every competing method, and on the real-world, 3D-scanned factory tasks it solved more than 90 percent of them, beating random sampling, genetic algorithms, and Bayesian optimization alike. On the difficult synthetic set with five goals and five obstacles, SGD found valid placements in roughly 57 percent of position-plus-orientation runs, compared with about 44.8 percent for random sampling and 39.4 percent for Bayesian optimization. The advantage appeared most strongly exactly where deployments are hardest: cluttered environments and tasks demanding many distinct reach targets.

Genetic algorithms, by contrast, claimed the prize for quality. Among the tasks each method managed to solve, GA delivered the lowest final cycle times on average, significantly undercutting both random sampling and Bayesian optimization across the full task suite. This edge was most pronounced in the edge-case set, where feasible base placements are squeezed into narrow zones; there, GA achieved an average best cycle time of about 14.3 seconds versus more than 17.5 seconds for Bayesian optimization. Bayesian optimization, often a darling of expensive black-box problems, fared worst overall, showing the lowest success rate on the constrained edge tasks when orientation was fixed, around 5.4 percent, and significantly higher costs than all other methods across the board.

The study also yielded practical lessons about the search space itself. Allowing the optimizer to choose the robot’s orientation as well as its position, rather than fixing the base facing, increased success rates on the hardest edge tasks for every algorithm, sometimes spectacularly: random sampling jumped from about 14.6 percent to 54.4 percent, and Bayesian optimization from 5.4 percent to 25 percent. The authors note this suggests that the extra mounting effort of a freely oriented base pays off for complex tasks. Generalization, however, came at a cost for everyone. Success rates dropped when methods tuned on simple tasks faced harder distributions, yet all algorithms still exceeded 80 percent success on the realistic factory scans, with SGD leading at better than 90 percent.

The contrast with the baseline is stark: a dummy optimizer that simply kept the nominal task pose solved only 47 percent of simple tasks, 18 percent of hard tasks, and not a single task from the real or edge sets. In other words, naively placing a robot where the task description happens to put it is frequently a recipe for failure or slow cycles, while even modest optimization effort pays for itself within a 20-minute compute budget. Because cycle time correlates positively with other costs such as energy consumption, faster cycles likely mean greener ones too.

Perhaps most importantly for the field, the entire comparison is now open. All benchmarks, implemented methods, tuned hyperparameters, and generated solutions are publicly available through the CoBRA platform and the team’s code repository, giving future researchers a standardized baseline against which novel placement algorithms can be measured. As robots grow lighter and more modular, requiring less sturdy foundations and inviting more frequent relocation, the ability to compute an optimal parking spot in minutes rather than engineer one by hand could become a standard step in every deployment. This study turns an intuitive art into a benchmarked science, and it suggests the smartest placement algorithms may be the same ones that taught machines to see and speak.

Subject of Research: Comparison of optimization algorithms for industrial robot base-pose placement

Article Title: Smart placement, faster robots—a comparison of algorithms for robot base-pose optimization

Article References: Mayer, M., & Althoff, M. (2026). Smart placement, faster robots—a comparison of algorithms for robot base-pose optimization. Frontiers in Manufacturing Technology, 5, Article 1642524. https://doi.org/10.3389/fmtec.2025.1642524

Image Credits: AI Generated

DOI: 10.3389/fmtec.2025.1642524

Keywords: industrial robots, base-pose optimization, robot placement, stochastic gradient descent, Adam optimizer, genetic algorithms, Bayesian optimization, benchmarking, manufacturing automation, inverse kinematics, cycle time, CoBRA

The material at the heart of the study is an elegant example of frugal chemistry. Rather than synthesizing an exotic new polymer from scratch, the team took ordinary commercial rubber bands and impregnated them with stearic acid, a cheap and abundant fatty acid, for two hours until the small molecule made up 31 percent of the blend by weight. The concept relies on a clever division of labor within the material. The cross-linked rubber network provides the permanent shape and the elastic restoring force, while the stearic acid acts as a switchable component. When the material is heated, the stearic acid melts and loses its crystalline structure, allowing the rubber to be deformed easily. When it is cooled, the stearic acid recrystallizes, physically locking the deformed shape in place. This swelling-based approach to creating shape memory polymers has attracted growing interest precisely because it transforms inexpensive, widely available elastomers into functional smart materials without complex synthesis.

Programming such a material follows what researchers call the classical hot thermomechanical cycle. The polymer is first heated above the melting transition of the switchable component, then mechanically deformed to a target strain, in this case 80 percent, and finally cooled while the deformation is held. The cooling stage is where the magic happens, or fails to happen. As the temperature drops, the stearic acid crystallizes and freezes the stretched network in its temporary configuration. But crystallization takes time, and during the window before the crystal network is fully established, the elastic rubber continues to fight back, slowly releasing some of the stored strain. The efficiency of the entire process therefore depends on how quickly and completely the material can be immobilized before that elastic recovery runs away with the programmed shape.

The Iraqi and Saudi Arabian research team asked a question that, surprisingly, has received little systematic attention: does it matter whether this cooling happens naturally at room temperature or is artificially accelerated with ice water? To find out, they compared two protocols. In the natural cooling condition, the deformed specimen was simply left to cool at ambient laboratory temperature of 23 degrees Celsius. In the artificial cooling condition, the specimen was first plunged into ice water at 10 degrees Celsius and then allowed to equilibrate at room temperature. The researchers then evaluated five key metrics of shape memory performance: the temporary shape fixity rate, the permanent shape recovery rate, the shape memory index, the recovery rate expressed as a strain measure, and a quantity they call the shape memory fill factor, which captures how close the material comes to ideal shape memory behavior.

The results were strikingly one-sided. Every single one of the five shape memory properties improved when artificial cooling was applied. The most dramatic difference emerged in how well the material held its programmed strain during the critical first ten minutes of cooling. Under natural cooling conditions, the specimen, which had been stretched to 80 percent strain, spontaneously released a whopping 57.7 percent of that strain within ten minutes. The rubber, in effect, was winning the tug-of-war against the slowly forming stearic acid crystals. Under artificial cooling, by contrast, only 9.6 percent of the strain was released in the same period. The rapid extraction of heat allowed the stearic acid to crystallize quickly enough to lock in the deformed configuration before the elastic network could recoil significantly.

This difference in strain retention cascaded directly into the overall economics of the shape memory cycle. Because natural cooling allowed so much strain to escape, the freezing stage had to be extended well beyond ten minutes to bring the shape memory fill factor of the naturally cooled specimen anywhere near that of the artificially cooled one and closer to ideal behavior. That extension proved costly. The total shape memory cycle time based on natural cooling stretched to 56 minutes, while the cycle completed with artificial cooling finished in just 36 minutes. In other words, a simple change in cooling technique, essentially the difference between a bucket of ice water and a passive wait, cut the cycle time by 20 minutes, a 36 percent reduction, while simultaneously delivering better shape fixity, better recovery, and a higher shape memory index.

The findings carry weight beyond the laboratory bench. In industrial settings, cycle time is money. Any process that requires nearly an hour to program a single part into its temporary shape faces an uphill battle for commercial adoption, whether the application is a deployable hinge, a packaging element, or a biomedical device. A 20-minute saving per cycle, achieved with equipment no more sophisticated than chilled water, could meaningfully change the throughput calculations for manufacturers considering shape memory polymers. The study also underscores a broader principle in materials engineering: the processing route is not merely a means of manufacturing a material but an active variable that shapes its functional performance. Two specimens of the identical rubber-stearic acid blend, programmed identically except for the cooling technique, behaved in measurably and dramatically different ways.

The work also fits into a growing body of research on fatty acid-switched shape memory elastomers. Previous studies have demonstrated that swelling cross-linked natural rubber with stearic acid or palmitic acid creates shape memory materials with tunable transition temperatures, and that the melting and crystallization behavior of the fatty acid network governs how mechanical deformation energy is stored and released during the cycle. Earlier work by some of the same authors characterized commercial rubber bands as shape memory materials and explored how cross-link density influences the shape memory effect in vulcanized natural rubber. The new study adds a practical but previously underexplored dimension to this literature by treating the cooling protocol itself as a design parameter, one that directly controls the competition between crystallization kinetics and elastic recovery that lies at the heart of the shape memory mechanism.

There remain open questions for future investigation. The study focused on a single stearic acid weight fraction of 31 percent and a single programming strain of 80 percent, leaving open how the cooling technique interacts with different compositions, strain levels, and deformation modes. The long-term durability of the material under repeated thermomechanical cycling, a known concern for shape memory polymer composites, was not the focus here. Nevertheless, the central message is clear and immediately actionable: for rubber-based shape memory polymers switched by small-molecule crystallization, artificial cooling is not a luxury but a necessity for functional efficiency. By chilling the material rapidly, engineers can freeze in more of the programmed strain, recover the original shape more completely, and slash the time each cycle demands. Sometimes the path to better smart materials runs not through novel chemistry but through a colder bucket of water.

Subject of Research: Effect of cooling technique on the shape memory performance and cycle time of a rubber/stearic acid shape memory polymer

Article Title: Effect of cooling technique on shape memory performance and cycle time of a rubber/stearic acid SMP in a classical hot thermomechanical cycle

Article References: Al Khader Abbas, R. A., Salim, E. T., & Qaeed, M. A. (2026). Effect of cooling technique on shape memory performance and cycle time of a rubber/stearic acid SMP in a classical hot thermomechanical cycle. Polymer Bulletin, 83(12), Article 674. https://doi.org/10.1007/s00289-026-06731-9

Image Credits: AI Generated

DOI: 10.1007/s00289-026-06731-9

Keywords: shape memory polymer, stearic acid, natural rubber, thermomechanical cycle, cooling technique, shape fixity, shape recovery, smart materials, crystallization, polymer processing, elastomer blend, cycle time