To be clear I’m not suggesting (and don’t believe) that velocity can be improved by reducing quality - that’s actually my point. To put it another way, the dim

To be clear I’m not suggesting (and don’t believe) that velocity can be improved by reducing quality - that’s actually my point. To put it another way, the dimensions of software projects are mostly invariant; absent an unlimited budget and unlimited time, one of the few effective knobs to fiddle with is the number of features shipped by a given time. The problem is that long term plans and detailed road maps attempt to make feature delivery invariant as well, which - IMO - is why at least 30% of IT projects still fail [0] - and of those that are said to have succeeded, many of them seem to have redefined success post-hoc. When we start to believe that delivering features to some inflexible plan decided 12 months ago is why we’re here, we’re well on the path to building crap. What’s important to me is to ship good software as quickly as possible, learn from the users, and be flexible and respectful about the future. [0] I’m sorry but it’s late and I’m too tired to pull out the PMI stats URL, but a cursory search should find the latest stats.