After a conversation of sorts about release early and release often it's clear that without a domain this notion is a very nice platitude with no way to test its applicability in an actual business and technical environment.
Like many conversations based on platitudes, it ends with do what works for you, with no actionable outcomes.
Let's Look from a Domain Point of View
The notion that releasing early assumes the customer can take the produced value early. That there are no externalities in the system. Since must systems are actually system of systems, the ability to accept early and often releases means there are no externalities. No externalities means - in our systems engineering dominated world of enterprise and software intensive systems - that the system is simple.
So for simple systems, sure early and often might be useful. Needs to be tested though with the business and the business rhythm of the business. Let's looks at several domains I work in:
- Enterprise IT - an ERP system integrated with legacy systems, and producers and consumers of information. Early releases into production impact other systems. This drives churn for those systems to also take early and often releases, causing further churn. This wastes resources. As well ERP systems have externalities from legacy or other business systems and processes.
- Real Time Systems - have interactions with external systems - the system under control. Early may mean that the system under control is not ready to use the release and has to be modified to accept the release when it is ready.
For Non-Trivial Systems - There's A Better Philosophy
Turn Early and Often into - Plan and Release - with margin for irreducible uncertainty and buy down for reducible uncertainty - for each of the needed capabilities, at the planned time, for the planned cost.
These releases and their dates, are of course be incremental value produced by the project against the planned value for the project as a whole. But the delivery of this value must coincide with the business's ability to not only accept the value, but to put this value it to work.
The chart below shows an enterprise project with externalities, in a health insurance domain. You can see that early and often has dependencies. It always has dependencies on any non-trivial system. All enterprise systems have interdependencies and externalities.
Accept the produced value into production. The last paragraph in the RERO philosophy is untested and likely unsubstantiated in practice. Like many of the agile philosophies devoid of a domain and a context.
I'm a direct user of agile. In Enterprise and DOD environments. But when I hear a phrase in the absence of a domain, context in that domain, specific assessment of the system architecture and related business process architecture, it tells me it's just a platitude.
And like all platitudes, you can't object to the words unless you have a basis of reality to stand on. Which is why it's easy to produce the platitudes but hard to apply them
