202205021252 Stock and flow

The fundamental observation of systems thinking is that the links between events are often more subtle than they appear.¹

Big changes appear to happen in the moment but there is usually a slow accumulation of small changes that lead to that moment.

Static values or accumulations are called stocks. They are how changes are stored over time. Stocks are the elements of the system that you can see, feel, count, or measure at a given time.²

Changes to the stocks are called flows.² These are rates of change. They can be inflows or outflows.

System dynamics are the relationships between different stocks and flows. For example, the rate of water pouring into a tub can be less than, equal to, or greater than the rate of water draining from the tub. This system dynamic can result in different long term outcomes like overflowing, equilibrium, or emptying.²

Keep in mind that stocks take time to change because flows (as units over time) require time to flow. As such stocks often act as delays or buffers in systems. They also produce lag in indication. Additionally, they allow the inflow and outflow rates to be different and temporarily out of balance. This creates feedback processes by which we monitor the inflows and outflows to keep a stock at some acceptable value.²

The concept of stocks and flows is best understood through example.

Developer Velocity Example

This example is taken from Will Larson's blog post on this topic.¹

How might we measure or define Developer Velocity? Typical definitions focus on four metrics.

1. Delivery lead time — the time from code being written to it being used in production
2. Deployment frequency — how often code is deployed
3. Change fail rate — how frequently changes fail
4. Time to restore service — time spent recovering from failures

A systems approach views these as points in the system and adds a much fuller picture. The purpose of stocks and flow is to allow us to actually reason about the system and make changes that will have a specific desired effect.

stateDiagram-v2
  direction LR
  prs : pull requests
  rcs : ready commits
  dcs : deployed commits
  vcs : reverted commits
  ics : incidents

  [*]-->pass : coding rate
  pass-->[*] : success rate
  pass-->fail : defect rate
  fail-->pass : debug rate

  state pass {
    direction TB
    prs-->rcs : code review rate
    rcs-->dcs : deploy rate
  }
  
  state fail {
    direction TB
    ics-->vcs : recovery rate
  }

• pull requests are converted into ready commits based on our code review rate,
• ready commits convert into deployed commits at deploy rate,
• deployed commits convert into incidents at defect rate,
• incidents are remediated into reverted commits at recovery rate,
• reverted commits are debugged into new pull requests at debug rate.

By making these connections, we can spot a feedback loop in defects that isn't accounted for in the simple metric approach.

Well written and thought-out models should show you obvious levers you can push and pull in order to change any of the stocks and flows that you care about.

For example, if you don’t have a backlog of ready commits, then speeding up your deploy rate may not be valuable. Likewise, if your defect rate is very low, then reducing your recovery time will have little impact on the system.