Comments by "TheEvertw" (@TheEvertw) on "Where Agile Gets It Wrong" video.

The key step for achieving Continuous Delivery is the automation of the deployment pipeline beyond running unit tests. When the pipeline also automatically runs integration tests and a set of acceptance tests, and then deploys the software if all is well, that is when you start getting the benefits of this style of working. Most teams are scared to automate the final parts of the pipe line, and have some sort of manual QA holding things up. Those teams will never see the benefits of QA. And most will have an over-worked Architect or QA team struggling to keep up with the changes.
22
I recently left a team because of the frustration of not being able to merge into `master`. Twice I had to spend two weeks of merging, catching up with other people, remerging, waiting for approval from the Architect, etc, and hoping to find a moment when nobody else was checking stuff in. At one point I got angry and demanded my changes got accepted without review and nobody merge anything into master until I got my changes merged into it. That was a 12-man team heavily using feature branches. I did stay until I felt I had done enough to fulfill my contract, then quit. I am all for committing directly into main (after some sanity checks & local unit tests). These complex acceptance procedures give a false sense of security, but in effect only raise frustration and stress levels.
11
@retagainez There was insufficient trust from Management, it wasn't a happy work environment. I was glad to leave, though I made excellent money.
3
@ForgottenKnight1 Nah. I had the privilege of re-designing a bit on the core of the system that had major impact on the rest of the system. In order to fix design errors that kept the system from fulfilling its scalability requirements. So basically every other checkin by anyone else required me to update my branch -- which required new approval by the QA people, etc. Business-wise, my update was THE most important that was being done: the product was not viable without it.
2
@Axel_Andersen There are few people who understand the different types of software better than this channel, and myself, having worked for 30 years in developing mainly firmware, but also other types of software.
2
@mikevidzdev All cooks are great chefs -- until another person tastes their creations. Likewise, software needs to be actually used to evaluate whether it is fit for purpose. The quicker feedback, the easier to fix problems. That is the theory behind CD.
2