[Jon Stratis]

Originally Posted by techhelpbb

Agreed. The team I lead is a DevOps team in an environment shifting towards our model:

The trick is that merely releasing frequently is pointless if the quality control feedback is not there. One needs to recognize that a 2 week scrum in an agile workflow is a soft deadline. One is supposed to evolve scheduling that matches the feedback from the working results. It's not unusual that major corporations merely setup 2 week scrums and make hard unyielding deadlines like it's a health check and then they realize that 'done' is not 'done'.

To make CI/CD work you have to work like a manufacturer. You have to adapt at each checkpoint changing direction to yield the best result with the resources you have. It's not just continuous deployment and integration it is also continuous improvement. I can't not express how many times that 'continuous improvement' part is totally lost on the people who think tossing Jenkins in will fix all their issues.

With just 6 weeks there is really a limit to what can really be delivered. It's a soft deadline that building 2 robots does change but at the cost of 2 robots. It's like forking a software development project because you know you are going to come up short.

Comparing the build season to agile development is a seriously flawed comparison. Stop build day is not the last day of a single sprint - it's the last day of the entire release, which was composed of many sprints (for my team 6, one sprint per week, which is a little shorter than most agile shops).