Definition of Done and conditional branching
I would like to hear people's opinions about whether or not a good Definition of Done might include branch conditions.
Would it be fair practice, for example, to include a deployment condition such as:
"If the increment corresponds to a Small Change Request, then it must be made available in the production environment by means of a Feature Switch which may be activated by the Requestor. For anything other than a Small Change Request, the increment must be reviewed by an authorized agent of the Change Control Board and made available to the Product Owner in a production-equivalent stage environment for potential release."
The risk of including conditionals in a DoD is clearly one of integration or deployment failure due to the increased complexity. However, that complexity can be managed, just as the complexity of non-linear code can be managed.
There is perhaps a reasonable case for including conditionals in an organizational DoD, because there may be many integration and release contexts across an enterprise, covering many products and services. This may be countered by making the organizational DoD sufficiently generalized to encompass them all, but it might then be too abstract to be useful.
I think such conditionals should be part of a Definition of Ready. Then it's clear from the story itself whether a feature switch is needed to make this story Done, without needing to refer to other systems.
I also think that the reporting lines are backwards in the last part of your example. It should be the Product Owner who reviews the increment, not the "authorized member of the Change Control Board". The Development Team should never have to wonder "who do I demonstrate this increment to? ".
Your example is a good case of the difference I see can between "continuous deployment" and "continuous delivery".
This DOD can contain something like "the increment is deployed", it is still up to the PO to ask for a deployment.
I agree that the team has to build a complexe switch mechanism, but it is probably not a big deal for a team that is able to have a good maturity and continuous deployment system.
oups, I mean "the increment is delivered", instead of "the increment is deployed", (not sure of my translation of the nuance between the two words but I sure you get my idea, right ?)
Thanks for the responses.
Please note that I'm less concerned about the example I gave, as it is just an illustration of how conditional branching in a DoD might arise. My real concern is whether or not it is appropriate to use branch conditions at all.
One way to look at it is to consider the promotion of generalized user story acceptance criteria to the Definition of Done. If these criteria are articulated in the form Given...Where...Then, we may see the case for supporting conditional logic.
On the other hand, this would increase the complexity of Done, and make a consistent and uniform assertion of quality harder to discern.
Risks I see:
- time consuming debates on what is a Small Change Request, what isn't
- a need for Conditional Branching might be a symptom of existing dependency between the Scrum Team and an organizational body that needs to "double check" the increment. In such case CB would institutionalize this dependency
Benefits I see:
- Conditional Branching could speed up the delivery of features with accepted risk of failure
- as part of desired DoD (as a tool of improvement) this could be a step toward continuous delivery
There is one item I would say is both risky and beneficial: when aforementioned Small Change Request is done mid-sprint, it could go straight on production environment. Why wait?
Another risk I see :
DOD is not only used to "check" the done work but also by the Dev Team to estimate the PBL, and then by the PO to order the PBL.
It might be more difficult for the Dev Team to estimate the PBI with a versatile DOD, isn't ?
Thanks. The institutionalization of dependencies, and an increased difficulty in making estimates, are both very good points.