I tooted on “Self Delivery” as alternative to Dogfooding that many feel has negative connotation…
Not liking other alternatives, such as “Icecreaming” (too vague), “Drink your own champaign” (too posh), and “Eat the food you cook” (too long).
A definition may be:
Self Delivery is a continual improvement method whereby the creator of a solution is also a client that uses it, gaining insight in how the solution conforms to stated needs, that are fed back into the design proces.
What I like in Self Delivery is that in software:
-
You have to “deliver”. Very often a solution does not match the needs of its stakeholders.
-
Delivery implies a process that is followed. A solution evolves in a software development lifecycle (SLDC), and the delivery are the “end products” of a supply chain.
-
So there’s not only emphasis on the process, the functionality, but also all the quality criteria that a successful delivery involves.
-
It fits in the same FSDL category as “Continuous Delivery” / “Continuous Improvement”.
“Self Delivery” fits better than “Dogfooding” in a non-developer context. Fits the SLDC / OSLC, which involves everyone that is directly or even indirectly participating in solution delivery.
The definition given above is short, easily explained. “We practice Self Delivery, meaning we rely on the software we build ourselves” is easy enough to understand by anyone. One may add the analogy:
“It is like eating what you cook. Us techies also call it Dogfooding sometimes. But Self Delivery is about more than just taste. It is about high quality, timely provided end results.”
Or something along these lines