Agile is a method of managing change by embracing it. It’s not a process, but there are lots of processes that help people deal with their particular change or their particular pain.
We talk about agile a lot as a method of developing code, and how the code needs to be flexible, reviewed, refactored, tested and changed to meet new requirements.
We talk a lot less about the processes around them. Yes, Continuous Integration and deployment are recommended, as are short sprints, and retrospectives should be about making all those better. But there’s too often a disconnect between the people and the processes they create. The processes may get reviewed, but often go without refactoring, testing or changing, so they slowly decay into legacy processes, and procedural debt, that are no longer fit for purpose.
So people work around them and suddenly there’s manual steps in production because a requirement to deal with secure data properly in production didn’t lead to the right refactoring of the CI/CD process.
So what’s your cycle for refactoring, testing, changing and reviewing your processes? Do they live in your code, and subject to the same cycle? Are they accessible and editable by all? Who needs to review them before they change? How do you know they’re failing the test?