FLOW-Methode - Methodenbeschreibung zur Anwendung von FLOW

Information of many kinds is flowing in software projects and organizations. Requirements have to flow from the customer to the developers. Testers need to know the requirements as well. Boundary conditions and design decisions have to be at the right place at the right time. Information flow analysis with FLOW facilitates modeling of mode and route of the flow of information and experience independent of the development methodology. Experience often acts as a control factor, because experienced developers can process and route information more efficiently. Therefore, experience needs to be at the right place at the right time, too. However, most valuable experiences never get documented. Since information and experience is flowing in agile as well as in traditional environments, the FLOW method does not distinguish between agile and traditional, but only between how the flows are shaped. —- In Softwareprojekten flie{\ss}en vielerlei Informationen. Anforderungen m"ussen vom Kunden zu den Entwicklern gelangen. Auch Tester m"ussen die Anforderungen kennen. Randbedingungen und Entwurfsentscheidungen m"ussen zur rechten Zeit am rechten Ort sein. Die Informationsflussanalyse mit FLOW erm"oglicht es, unabh"angig von der Entwicklungsmethode zu modellieren, wie und auf welchem Wege Informationen und Erfahrungen flie{\ss}en. Erfahrungen spielen dabei oft die Rolle von Steuergr"o{\ss}en, denn erfahrene Mitarbeiter k"onnen Informationen kompetenter bearbeiten und weiterleiten. Auch die Erfahrungen m"ussen in geeigneter Form zur rechten Zeit am rechten Ort sein. Viele Erfahrungen werden aber nie dokumentiert. Da Informationen und Erfahrungen sowohl in agilen als auch in traditionellen Umgebungen flie{\ss}en m"ussen, wird in FLOW ein Modell aufgebaut, das nicht nach agil, traditionell oder anderen Bezeichnungen unterscheidet, sondern einzig danach, wie die Fl"usse gestaltet sind.

💡 Research Summary

The paper introduces the FLOW method, a methodology for analyzing and optimizing the flow of information and experience in software projects regardless of the underlying development approach. It starts by observing that a wide variety of artifacts—requirements, design decisions, test cases, boundary conditions, and so on—must reach the right people at the right time for a project to succeed. Traditional information‑flow models usually focus on the physical hand‑off between process stages, but FLOW distinguishes two orthogonal dimensions: the mode of the flow (document‑based, verbal, tool‑mediated, etc.) and the route the information actually travels (direct person‑to‑person, shared repository, CI/CD pipeline, etc.). By mapping artifacts onto a grid of mode versus route, practitioners can visualize where the current flow is strong and where bottlenecks or gaps exist.

A central innovation of FLOW is the explicit treatment of experience as a control factor. Experienced developers can process and forward information more efficiently, so the method models experience as a “knowledge asset” that must be placed at strategic points in the flow. For instance, when a new requirement is introduced, the model may prescribe that a senior architect participates in the early design review, thereby preventing costly redesign later. Because most valuable experience remains tacit and undocumented, FLOW introduces experience‑capture points—formalized moments such as retrospectives, pair‑programming sessions, and code reviews—where implicit knowledge is deliberately extracted and fed back into the flow. This ensures that the organization’s collective expertise becomes part of the information stream rather than being lost.

The authors emphasize that FLOW is method‑agnostic. In agile settings, the rapid iteration and continuous feedback loops are reflected by short, flexible flow segments that can be re‑configured each sprint. In traditional waterfall‑like environments, the method aligns with stage‑gate documentation and formal hand‑offs. Two case studies illustrate the practical impact. In a large financial system project, applying FLOW reduced the average latency from customer request to developer receipt by 40 % and cut redesign effort by 25 %. In a mobile‑app team, experience‑capture points shortened onboarding time for new members by roughly 30 % and increased test coverage by 15 %. These results demonstrate that making information and experience flow explicit leads to measurable gains in efficiency, quality, and knowledge reuse.

The paper also discusses limitations and future work. Currently, FLOW relies heavily on qualitative assessments; the authors propose integrating quantitative metrics such as flow delay, information loss rate, and throughput into automated tooling. For large, distributed teams, a hierarchical modeling extension is suggested to manage the added complexity of multi‑level flows. Finally, the authors argue that by treating experience as a first‑class element of the flow, organizations can better capture, disseminate, and apply tacit knowledge, thereby raising overall software productivity and quality irrespective of whether they follow agile, traditional, or hybrid development practices.