The Goal

Key Takeaways & Highlights

• The fallacy of optimizing for local maximums

• Bottlenecks

  • The only optimizations come from optimizing your bottlenecks

  • Our bottlenecks should be running as close to non-stop as they can be

    • Downtime or unutilized time for the bottleneck is time lost for the whole system

    • Balancing infinite potential batch-size with velocity

• Non-Bottlenecks

  • Optimizations made if non-bottleneck areas are a mirage

• Small batch sizes > Large batch sizes

• Very manufacturing-oriented, so I’m still thinking about how it translates to software

  • Bottlenecks, Constraints, statistical anomalies, dependant events,... sounds like a deployment pipeline

  • Learnings

    • Our bottlenecks should be running as close to non-stop as they can be

      • Downtime or unutilized time for the bottleneck is time lost for the whole system

      • Balancing infinite potential batch-size with velocity

    • The whole system is constrained by the constraints placed on or determined by the bottlenecks

      •  we can only release as fast as a TeamCity deployment allows us to release 

      • I.e., the throughput of the whole system is determined by the throughput potential of the bottleneck.

    • Eliminate dead weight early in the pipeline

      • Tests failing during or after the bottleneck (deployment to UAT from TC) are more expensive than tests failing before the bottleneck

      • Be able to run tests effectively & locally

    • Smaller batch sizes 

      • Increases cost per unit, but also increases velocity and agility