I like git-flow, however I always seem to run into the same problem. When feature requires client or external stakeholder feedback before it could be considered done, where does that fit? External feedback could come back in minutes or months and doesn't make sense to block a release.
That's on the stakeholder, and you need to set a deadline for their feedback. If feedback is still absent at the deadline, and the PR passes tests, (dev team) review, and definition of done, you push the release without them. If you never got the feedback required to complete, you make a decision on what to do with it (keep the branch alive while rebasing, save a diff, or just kill it, and close the issue as stale due to no feedback).
The key in either case is to document your attempts to get feedback and the stakeholder's failure to provide it (CYA).
Maybe it's because I am viewing this as an agency, but none of that seems possible.
The definition of done requires the client's approval as something cannot be released to a client's site/app/service without their approval. Going back to a client with "The change needs to be re-tested " when they finally provide their feedback is a good way to end up with unhappy clients.
I wasn't speaking specifically to clients (many stakeholders are internal, and I've worked numerous projects where all of them were), but even with external clients, you need language in the contract for cases where they are not responsive.
And sure, it is often the case that the feature just doesn't get pushed (but the client is still billed for your time) if they fail fulfill their obligation as a stakeholder.
I've observed that client feedback requires them to see a working demo. And so to solve that problem, we do weekly demos. I really encourage daily demos (doubling down on the principle of short feedback loops to help me mitigate alignment issues).
Then the problem becomes, how do I deploy this version so that I can demo it. This is where having a Developer Enablement Platform (fancy word for k8s or Cloud Foundry or some Platform as a Service that lets developers deploy versions from their machine or pipeline) helps enable this. I fully acknowledge that this can be hard, politically, technically and financially :(
I like git-flow, however I always seem to run into the same problem. When feature requires client or external stakeholder feedback before it could be considered done, where does that fit? External feedback could come back in minutes or months and doesn't make sense to block a release.
That's on the stakeholder, and you need to set a deadline for their feedback. If feedback is still absent at the deadline, and the PR passes tests, (dev team) review, and definition of done, you push the release without them. If you never got the feedback required to complete, you make a decision on what to do with it (keep the branch alive while rebasing, save a diff, or just kill it, and close the issue as stale due to no feedback).
The key in either case is to document your attempts to get feedback and the stakeholder's failure to provide it (CYA).
Maybe it's because I am viewing this as an agency, but none of that seems possible.
The definition of done requires the client's approval as something cannot be released to a client's site/app/service without their approval. Going back to a client with "The change needs to be re-tested " when they finally provide their feedback is a good way to end up with unhappy clients.
I wasn't speaking specifically to clients (many stakeholders are internal, and I've worked numerous projects where all of them were), but even with external clients, you need language in the contract for cases where they are not responsive.
And sure, it is often the case that the feature just doesn't get pushed (but the client is still billed for your time) if they fail fulfill their obligation as a stakeholder.
And again, CYA applies universally.
I've observed that client feedback requires them to see a working demo. And so to solve that problem, we do weekly demos. I really encourage daily demos (doubling down on the principle of short feedback loops to help me mitigate alignment issues).
Then the problem becomes, how do I deploy this version so that I can demo it. This is where having a Developer Enablement Platform (fancy word for k8s or Cloud Foundry or some Platform as a Service that lets developers deploy versions from their machine or pipeline) helps enable this. I fully acknowledge that this can be hard, politically, technically and financially :(
BTW, I've used glitch.com as a way to demo.
That entirely depends on the client...
Thanks for your reply...😊