Probabilistic Planning and Decision Support

Peter Drucker is recognized as the greatest philosopher and management theorist in history. To him we owe the evolution of the postulates of the industrial revolution to the new model of economy that arises as a result of automation and transition to a type of intellectual work, based on planning and the development of logarithmic value; knowledge instead of the arithmetic progression of physical and manual labor.

He established 70 years ago the increasing contribution to the GDP of industrialized societies of the intellectual factor at work and gave rise to the concept of the information and knowledge society as a concept in which synergies, connections and relationships between isolated nodes increase the value of the model.

In this framework, assumptions about the future are constant. Projections are increasingly risky as more and more variables enter the fray where a linear advance is replaced by various multiplying factors. In an intellectual work, things take as long as they take and estimates are not certain.

In an agile environment assumptions are validated by delivering value early and often. That value delivery involves estimating what and by when. Concrete estimates are a weak opponent against the realm of the unknown, but the fear of uncertainty is greater than the fear of being wrong.

Estimates are predictions based on assumptions or feelings. A concrete, definite number. And they consistently fail miserably. They create a sense of urgency and cascade into subsequent estimates, like a huge house of cards of dates and promises.

Predictions are based on historical data. They are communicated as a range of values and the probability of their occurrence. They are more accurate, simpler and provide confidence, since they represent what happened in the past to forecast future behavior.

Little’s Law

Continuous development is a constant flow of inputs and outputs, precedents and consequences, a queue. To manage that input and output, or at least explain it, the various approaches to Agile draw on Little’s Law to achieve the predictability that a stable system provides.

In short, Little’s Law tells us that the amount of work in the flow (the Work in Process or WIP) divided by the number of units of work leaving the system in a given period, for example, 14 tasks per month (Throughput) must be equal to the cycle time from the start of development by the team until it leaves the flow (Cycle Time).

In effective queue management the limits associated with each process must be satisfied before incorporating new tasks. Limiting the work in progress allows the effort to be focused on delivering value, not on receiving execution inputs. Therefore, we focus on WIP, i.e. WIP = Throughput * Cycle Time.

For example, let’s say we run a great bookstore in town where 10 customers come in an hour looking for good literature; each one takes 30 minutes to decide from the available catalog and when they get it, they pay and leave. That means that five attentive readers are strolling through our store at any given time.

Well, let’s turn to Little’s Law formula which tells us that WIP = Throughput * Cycle Time. That is, 10 customers/hour * 0.5 hours spent in the store = 5 customers.

Little’s Law makes certain necessary assumptions:

• The average input equals the average output.
• Everything that enters the system will eventually exit once completed, from left to right.
• The WIP of the period under examination must be stable.
• The Work Item Age (age of an item in the workflow) should be regular, with no increases or decreases.
• Consistent units of measurement must be used between Cycle Time, WiP and Throughput, i.e. if we use a monthly reference we cannot mix it with weekly references.

Little’s law only deals with averages. Making predictions based on averages can be dangerous if the individual metrics and their distribution are not fully understood. If there is no way to achieve percentile associations with the reflected mean, we could be exactly 50% above or below. With this variability it is not possible to make any decision. Little’s law alone is of no use. Its value lies in understanding the metrics behind it.

Daniel Vacanti, co-author of the Kanban guide and one of its pioneers tells us to “forget the equation and focus on the assumptions” that make Little’s Law work. Once those guidelines are followed, the flow is stable and predictable, and the metrics are easy to calculate.

Cycle time

The cycle time (CT = WIP / Throughput) is the time a task is in progress. It calculates the time spent within the workflow passing through each of the processes. Calculating the Cycle time allows to establish the performance of a team. Short cycle times imply efficiency, long cycle times imply bottlenecks, blockages, refinement problems. A short cycle time leads to a reduction in lead time, and therefore to greater customer and stakeholder satisfaction, since it would measure the time from the time they express an idea as a desire until they see it consummated.

The graphs represent a histogram reflecting the times of all tasks within a system. A grouping is observed that relates them to the type of demand, the queue being distorted by management tasks in a complex environment. By being able to filter by class of service, percentile-based estimates are possible.

Throughput

The amount of work leaving the system in a given period. This metric only contemplates delivered items. A decrease in delivered tasks could indicate in a stable input and output flow that the team is encountering problems during the flow.

Knowing the histogram by type of demand and class of service of the number of tasks per unit of time allows to plan probabilistically the number of items per iteration and to be able to establish product increments according to the prioritized items of the backlog.

WIP

A WIP Limit indicates the maximum number of items that can be found in a process or state within a workflow. Once this limit is reached, the task must move forward to make room for others to enter.

Reviewing Little’s Law we see that WIP is related to Throughput and Cycle time, so limiting WIP usually causes a decrease in Cycle time and work is delivered sooner. It is not a linear relationship and each system is different, so there is not a direct effect, but a conditional one, since a very low limit would cause team members to have no real tasks to collaborate with.

How to introduce the probabilistic approach in a work team

Metrics only have value if the data obtained are valuable. It is a team effort that must be especially strict in reflecting the work in the system. The work and its reflection must be transparent and rigorous, the stability of a system, its predictability and data-driven decision making depends on workflow management. It is the key to continuous improvement based on objective facts, not feelings or opinions.

The metrics and exposure of a system always face rejection of auditing. Pedagogical work is needed to convey that metrics are oriented to flow efficiency, not to control team members.  To achieve this, make policies explicit, make metrics always accessible and explain them. Report their relevance to decision making, not team performance. Metrics highlight problems in the system and help manage demand and delivery based on customer and stakeholder needs.

Metrics do not restrict freedom or limit in any way; on the contrary, since decisions are made based on data, you lose the fear of not acting because you are wrong. Understanding metrics and their impact on a system will make you work consciously on finishing tasks, without giving effort to the input of demands. 

Autonomous and mature teams generate more consistent data because their results are consistent. Different perspectives and experiences foster collaboration and reduce the occurrence of risk by being proactive in participation.

Without metrics there are no systems, flows or processes because their constitution is not endorsed by objective data but by sensations and opinions. Changes or actions cannot be compared and the decision-making process cannot be justified or supported. Metrics are not opinionated, they are data, numbers that reflect a state and a trend to propose actions.

Image: Unsplash | @soymeraki