Comments by "Andrea Laforgia" (@andrealaforgia) on "14 Step Continuous Delivery Checklist" video.

Nope, you don't need that. Adopt continuous integration, no matter what the size of a feature is. Big features should still be broken down into valuable slices deliverable frequently and continuously. If you adopt trunk-based development, you can hide any incomplete functionality behind a feature toggle (if there's no other way). The longer you stay on a branch, the later your changes will be integrated, the more serious will be your merging problems, the less confident you are that your complete feature is not going to break other stuff.
2
@ContinuousDelivery Should we change "Continuous Delivery" to "Continuous Deliverability"? 🤣🙃
2
Continuous Delivery is the material foundation of agility. Working agilely means collaborating with the customer by releasing valuable working software as frequently as possible, in continuous small batches. The needs of the customer are continuously evaluated and wasting the customer’s budget on potentially useless features is avoided. The tools/methods here are those that enable us to satisfy our customers via early and continuous delivery of valuable software. Do you know a better way of working?
2
There are plenty of examples on the internet when searching for "CD pipeline". Tools, however, are irrelevant. What counts is the principles.😊
1
Every developer working on a different part of the system is not a team. It's a group of individuals each working in their own silo.
1
@INFOXlive I’m amused by your comment 😄. The first principle in the Agile Manifesto states: “our highest priority is to satisfy our customers via early and continuous delivery of valuable software”. The fact that software must be delivered continuously is specifically stated in that foundational principle of Agile, so I don’t understand where you see the falsity in my statement. The Agile Manifesto contains a set of values and principles that foster agility: the ability to respond to change quickly. I was asking you a specific question: do you know a better way of working? That’s the opposite of being dogmatic. I’m all ears. I’m open to learning a better way from you. How do you think software should be engineered if not following the points that Dave is mentioning in this video? You say that they are meaningless but you offer no alternative. What do you think is an advisable way to engineer software so to meet targets more quickly, effectively and with higher quality standards?
1