"Developers change things quickly, release often, and measure success by the rate of delivery. Operations are driven by maintaining stability of the application. Frequent releases are a cause for concern of the stability and reliability of the application on the supported platforms, especially during high network traffic."
Another bit of text later on seems to have a typo -- i.e. a bug -- which is just funny:
"With DevOps, you can quickly while retaining control and preserving compliance. Use automated compliance policies, fine-grained controls, and configuration management techniques. Monitor for security incidents and adjust your configurations and software as needed. For example, using policy as code you can define and then track compliance at scale."
It's mainly interesting to me because, of the 18Z pro-Agile articles and the 19Z anti-Agile articles I've read, none seemed to talk about this aspect of Agile -- end product reliability.
Granted, this AWS course is about 'Devops' -- its culture and processes and tools -- not 'Agile' -- but Devops, to me, is driven by Agile, CI/CD, etc.
If it is true that Agile leads to, or can lead to, or has a higher risk of leading to, less reliable software, then I would like to see some more truth in advertising going forward.
And, if there is a way to Sprint but still maintain or even increase the reliability of the end product (over/instead of a non-Agile dev process), I'd like to know what those techniques/safeties are.
Remember project management triangle: time, scope, quality.
The more time you put into development or testing, the less bugs you may find.
The less scopes you push into the application, the less bugs you may get.
In agile, you need to decide the least scope with the least time to develop an acceptable quality of working product. New changes introduce a new complexity to the software, and devs need time to formulate the right complexity. You need to make a balance between time or scope, or the complexity of the software will produce either less testable or less readable codes, which leads to more buggy app.
If the agile approach seemed to be cause of it, then the agile process must have been conducted improperly.
I’ve seen many agile shops fail to ever get CI/CD working because the effort just couldn’t find a place and a schedule on the backlog.
Now if you imagine a waterfall project that delivers the entire feature-complete v1.0 product, I can imagine that this is much more likely given that real-world volume testing happens after shipping/launching it.
With a product that evolves with its user base, acquiring features as users gain experience to demand it, all the while being used and exercised by the user base, it will also have bugs along the way, but there may be many more opportunities for course corrections that are achievable without a full rewrite.
There's is also every combination in-between and what makes sense depends on the specific subject area and users.
Regardless of which approach one takes, quality/lack-of-bugs depends on making it a priority and sufficient investment. i.e. it is not only/predominantly based on process, it's in the details.
CI/CD seem to fit Agile better because you do not get a discontinuity of how a project is managed. But that by itself does not tell you if CI/CD is better or worse than QA phases of alpha and beta and a traditional test plan based on a functional spec.
The CI/CD advantage is that you do not need a comprehensive test plan to start, and you start testing early. The disadvantage is that if what you have by the time you decide to ship does not cover both implementation and features you do not have test coverage, with the predictable problems.
TDD and/or FDD can help you track whether you have test coverage. But if you do not have coverage, and you do not have regression testing, deploying will be painful, whether it is continuous or not.
XP practices, in my experience, do lead to high technical quality.
High stakeholder interaction and feedback tends to lead to improved fitness-for-purpose.
Many teams professing to be “Agile” don’t do either of these things.