Randall Munroe of XKCD with a nice example of why useful rules of thumb that apply well in one context don’t always apply elsewhere…
I hear lots of these. People with a software background seem to be really good at “generalising the particular”.
One piece flow = good.
Push = bad.
Estimates = waste.
Prioritisation = waste.
So on, and so forth. I could probably also be accused of doing this, but sometimes it is hard to convey nuance (see my comment on that piece), especially on a quantum-constrained medium, like Twitter. My suggestion to take a different approach only applies to a specific context (i.e. Product Development). It is in that context where wrapping things up into a delivery vehicle called “projects” tends to negatively affect the asymmetry of the payoff function.
Where “Move fast and break things” can make perfect sense is in anti-fragile systems. These are systems that aren’t just resilient to us breaking things, they are systems that actually improve when we break things. In effect, they “learn”. In the product development context, the improvement opportunity lies in the generating of valuable information about what doesn’t work. Whilst it might not feel like it, that information often has value. Crucially, if there is no feedback loop in place that is paying attention to this mechanism then the learning opportunity is being lost. Perhaps we could update the motto, to something like.
“Move fast, and if you break things in the process make sure to learn from it”*
(*Only applies in certain contexts).
Hmm. Not quite so catchy, is it? Either way, don’t be fooled into thinking that breaking stuff is inherently good. It’s not. And it obviously doesn’t apply in all contexts, as the XKCD comic demonstrates.