With empirical process control we neither fix the scope of the product nor the process of how to build it. Instead, in short cycles we create a small shippable slice of the product. We inspect what we have and how we created it, and adapt the product and the way we create it.

If we were to build a new version of the Drift customer dashboard – lets call it “Dashboard 2.0” – we ’d have two options: We could ship the entire thing at once and take two weeks to do that, or… We could ship five different incremental updates to customers in two-day bursts.

We start with just enough design to get the feedback cycles going: Features What do users want? Design How can programmers best be supported to deliver those features?

Keep innovation and maintenance together. A frequent practice is to spin up a new team to innovate while existing teams are bogged down in maintenance. I’ve historically done this myself, but I’ve moved toward innovating within existing teams.5 This requires very deliberate decision-making and some bravery, but in exchange you’ll get higher morale