The key to delivering software as quickly as possibly is to have as little process as possible but place value on things that actually give you confidence.
Ask your engineers, if we deployed every commit to live; what would it take for you to not be scared?
Tests. No manual testing allowed if you're practising continuous delivery
Monitoring, so you know if something has gone wrong
Green/blue deployments
Pair programming
Breaking down stories into small tasks. If you're shipping small things frequently then the risk is low.
Yes I do, it's very nice and teams I have worked on have always been less stressed, more productive and happier compared to teams that release weekly/monthly
Re the business
It's important to distinguish between business requirements and technical activities.
Files moving from one server to the other (i.e deploying) is not a business concern. Just like how creating functions is not a business concern.
Depending on the business it is better to ship features when they're ready even in an MVP state. But if the business wants/needs control, use feature flags.
edit-
Due to the fast feedback, iterative nature of continuous delivery business requirements are generally more based on actual real feedback rather than guesses. In addition because we can ship things easier they are more open to trying different ideas. So CD is not only a technical win but a business one too. It changes the way the business works for the better.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The key to delivering software as quickly as possibly is to have as little process as possible but place value on things that actually give you confidence.
Ask your engineers, if we deployed every commit to live; what would it take for you to not be scared?
Scrum, kanban, etc are all distractions honestly.
Do you currently work that way? How are business priorities reflected in your way of working?
Yes I do, it's very nice and teams I have worked on have always been less stressed, more productive and happier compared to teams that release weekly/monthly
Re the business
It's important to distinguish between business requirements and technical activities.
Files moving from one server to the other (i.e deploying) is not a business concern. Just like how creating functions is not a business concern.
Depending on the business it is better to ship features when they're ready even in an MVP state. But if the business wants/needs control, use feature flags.
edit-
Due to the fast feedback, iterative nature of continuous delivery business requirements are generally more based on actual real feedback rather than guesses. In addition because we can ship things easier they are more open to trying different ideas. So CD is not only a technical win but a business one too. It changes the way the business works for the better.