Beyond the vitriol-inducing and wonderfully attention-grabbing title, the real point that I believe Simon is making is that depending on the maturity of a given 'component', more on what that might be in a bit, the focus of the applicable development process to be applied to its development will change.
In place of 'component' I might use microservice, mainly to make explicit the principles of the component/microservice being independently evolvable that is more explicit in the microservices goals and terminology.
Initially a component, or even feature, is badly understood and you're in a process of research and development as you discover what is needed. The focus here is on embracing change, and antifragile processes and architectures, such as microservices can be, seem to open up the most options during this phase.
As the component/microservice continues through its lifecycle Simon suggests that the focus moves to waste removal and improved measurements (lean) and reducing deviation (six sigma).
So process is a component/service-level concern, not a project-wide one, and I cannot agree more on this.
Where does this leave Antifragile Software & Microservices?
Following that logic this means I would tend to develop microservices for maximum options and flexibility early on while discovering what is needed and then keep those options, exercising them less, as the system progresses and the component/microservice's maturity and stability levels out.
If the User Experience (DevOps Experience) of Microservices was great then this would be true, but...
At the moment, microservice-related technologies and the emergent UX of their use are too clunky for me to discover and develop a domain quickly as well as deal with the technology inertia present.
As I've mentioned in a number of talks now, and as I present and talk through with my attendees on the Building Microservices course, from a green-field start at the moment I tend to develop a modular-monolith that is ready to break out into microservices as this is quicker to get started with and introduces less overhead when all the attention needs to be on discovering the domain itself.
I then break out the services as soon as possible... but this then means I'm not getting the real benefits of the agility of microservices early on in a component/service's life when it needs it most!
As part of the Antifragile Software book I think it's about time I turned the Wardley Map lens on the emergent microservices-associated technologies and practices; containers, cloud-native technologies, event-stores and the like to see if there's a better Microservices UX that can be constructed.
This could be an interesting journey and I'll share all of it here and in the book.