Just like that rebrand cycle years ago when RUP consultants transitioned over to scrum masters through staged re-titling on LinkedIn and liberal use of search / replace in their CV, scaled agile frameworks and certified project managers attempt to apply the agile manifesto to large organisations by bringing in processes and tools to manage the individuals and interactions, comprehensive documentation of the working software, to negotiate contracts to manage customer collaboration and make plans for how to respond to changes. You start seeing concepts like the Agile Release Train, which are – well – absurd.
Why? Do they not see what they are doing? Are they Evil?
No – I think it’s simple – and really really hard, at the same time.
You cannot respond to change quickly if you have delays in the system. These delays could be things like manual regression testing due to lack of automated test coverage, insufficient or badly configured tooling around the release or having a test stack that is an inverted pyramid, where you rely on a big stack of UI tests to cover the entire feature set of the application because faster, lower level tests aren’t covering all the features and you have undeniable experience of users finding bugs for you.
Obviously, if these tests are all you have, you need to run them before releasing or you would alienate customers. If your software stack is highly coupled, it would be irresponsible to not coordinate carefully when making changes on shared components with less-than-stellar contract test coverage. You are stuck with this, and it is easy to just give up. The actual solution is to first shorten the time it takes from deciding you have all the features you want to release until the software is actually live. This means automate everything that isn’t automated (the release itself, the necessary tests, et c) which could very well be a “let’s just stop developing features and focus all our attention on this until this is in place” type investment, the gains are so great. After this initial push you need to make an investment into decoupling software components into bits that can be released independently. This can be done incrementally whilst normal business is progressing.
Once you have reached the minimum bar of being able to release whatever you want at any time you want and be confident that each change is small enough that you can roll them back in the unlikely event that the automated tests missed something, then you are in a position to talk about an agile process, because now teams are empowered and independent enough that you only need to coordinate in very special cases, where you can bring in ad hoc product and technical leadership, but in the day to day, product and engineering together will make very quick progress in independent teams without holding each other up.
When you can release small changes, you can all of a sudden see the value in delivering features in smaller chunks with feature flags, because you can understand the value in making 20 small changes in trunk (main for you zoomers) rather than a massive feature branch, as releases go live several times a day, and the benefit of your colleagues seeing your feature flagged changes start appearing from beginning to end, they can work with your massive refactor rather than be surprised when you open a 100 file PR at 16:45 on a Friday.