Flow Oriented Organization Design

Agile – and Lean – focus on a holistic, continuous flow of end-to-end development (“from concept to cash”). The most important element of the evaluation is the value achieved. In contrast, traditional project management tends to focus more on the process. The added value is created quasi incidentally.

At the heart of an effective product development flow are a few key principles .[Reinertsen 2009] They facilitate an assessment of how specific goals can be achieved and how this needs to be adapted to the culture and environment of the company.

Don Reinertsen has compiled the most important heuristics as nine rules. Many of these heuristics can be found in Kanban and SAFe.

#1: Take an economic point of view

Build an explicit decision framework for the specific context. This has to be done separately at different levels: at team level, at programme level or at company level.

This decision framework must be based on an understanding of the entire value chain and focus on optimizing future flow. It forms the basis for decisions to be made locally, because it ensures a consistent target system.

Reinertsen describes five typical elements of such a framework:

• Development costs – The cost of developing a decision or acquiring a capability.

• Cycle time – The time to implement the decision
• Costs – The costs of production, delivery and operation
• Value – The value of the decision for the company and for the customers
• Risk – The increase or reduction of uncertainty or the technical viability of the solution.

If value maximization is to be achieved, specific attention must be paid to getting the most important activities done first. In particular, this means prioritizing high risk, low cost activities.

Opportunity costs (cost of delay) play a special role here. Reinertsen recommends that this point of view be considered first.

#2: Think in systems

A special place is given to the integration of systems thinking, as formulated by William Edwards Deming [Deming 2000]. Deming repeatedly calls for developing an overall view of a system and taking a longer-term perspective. The main theses from this point of view are:

• A system must have an intention in order to function purposefully.

• Optimizing one part does not have to optimize the entire system.
• A system cannot move faster than its slowest integration point.
• Apply a continuous improvement process.

These views are applied to the developed system, i.e. to the product and also to the company as a system.

Another of Deming’s theses is also built into SAFe at a fundamental point: Only management can change a system [Deming 1993]. Therefore, the management at SAFe for the development and for the structuring of leadership and company culture.

#3: Expect variability – preserve options

In manufacturing, you try to reduce variability as much as possible to achieve predictable results, efficiency and quality. This cannot be the goal in software development, because we do not have serial production, but “individual production” and strong innovative and creative elements. Variability is therefore inevitable and to some extent necessary.

Instead, one should design systems that can handle variability, and take advantage of it when possible. This helps to make decisions later and keep options open until more information is available to make a decision.

In agile development, we know the related requirement “embrace change” and the central activity of regular prioritization in the course of development, which take these realities into account.

#4: Develop incrementally with fast integrated learning cycles

Fast feedback is achieved through short planning cycles. With “spikes”, i.e. targeted prototypical implementations, one can avoid too much uncertainty and generate more knowledge. They are part of an effort to reduce unwanted uncertainty through targeted rapid feedback.

In agile development, such feedback cycles are built in at various levels:

• Agile testing, test automation, continuous integration

• daily scrum
• Sprint review, short iterations and regular releases
• Learning at team and program level through the Retrospectives and Inspect & Adapt meetings.

In scaled agile development, you need to explicitly plan for such feedback or integration points for the overall system (see also #5).

#5: Set milestones based on objective evaluation of running systems

Phase-based milestones only allow a limited objective measurement of the actual development progress. The margins for evaluation are too subjective and too large. In the negative case, wishful thinking plays too large a role in the evaluation.

With milestones built on executable functionality of a system, many of these imponderables are eliminated and replaced with objectively measurable progress (i.e., completion of epics, features, and user stories). This also makes it easier to keep alternatives open, set up experiments to expand knowledge, and replace functionality if necessary.

#6: Visualize and limit WIP limits, reduce lot sizes and manage queue length

Long queues are responsible for longer cycle times, higher risks, poorer quality and less motivation. Queues must be actively managed to achieve predictable short waiting times.

The main tools to control queues are small batch sizes and limiting the number of issues worked on at the same time (work-in-progress or WIP limit).

The queues at the different levels of SAFe are the backlogs of the teams, the release trains and the whole portfolio.

#7: Use cadences and synchronize across domains

The tools to control the flow of development under uncertainty are cadence and synchronization.

Cadence means developing in a predictable, regular rhythm (like the sprint) that helps transform unpredictable events into predictable developments. Cadences make waiting times predictable, transaction costs lower and the reliability of product development increases.

Regular synchronization allows to encapsulate the variance and tuning problems into a single interval. Regular system-wide integration helps to achieve reliable system testing and an objective assessment of the project status. Regular synchronization supports the alignment of competing goals and the high-bandwidth transfer of information to focus on a global optimum.

#8: Develop the intrinsic motivation of knowledge workers

Knowledge workers are individuals who often know more about their work than their supervisors. Meaningful control of the results is generally not possible without their active participation.

This has profound consequences for the nature – and necessity – of motivation: it must come from within, be intrinsic. Knowledge workers usually function best when they have a challenging task and extensive freedom to implement it. At the same time, this results in another necessity: you need to know more about the goals and the global optimization of the system in order to be able to make target-oriented decisions. This results in significantly different demands on the style and actions of management.

#9: Decentralize decision making

During a development, decisions have to be made continuously. Delays in the decision-making process worsen the quality of the decision due to new findings in the meantime or changes in the framework conditions.

Teams need to be empowered to make decisions and act quickly and effectively. But they have to be willing to do that. There are close cross-relationships here with principles #2 (systems thinking) and #8 (intrinsic motivation).