,
10 tweets,
2 min read
Read on Twitter
Agile is not a product you buy and install. A certain department cannot be in charge of or own "agile". Agile is a way of thinking about your work, of organizing your processes. If you think you can just buy something, or appoint an "agile" group, you don't understand it.
Agile methods are also not more dangerous than "waterfall". The whole point is that the old way of doing things involved unacceptable business risk masquerading behind fake certainty created by processes that could never actually work. Agile reduces risk, that's the point of it.
Having many layers of approval for every change in your systems does not reduce risk. It increases risk, adds latency, and wastes the time of managers without having any obvious benefit other than using committees to keep single individuals from being blamed for mistakes.
If you are worried that something might go wrong with new systems you deploy, add automated tests for those things instead of asking managers whether they think a code change is safe. If you can't automate your tests, that's your problem, not a lack of approval layers.
Humans cannot figure out by staring at a change approval request form whether a change is safe or not. There is no information in that form that tells you anything useful. Only an automated test can tell you that. The forms are cargo cult management.
They seem like they do something useful. "Don't well run companies have lots of forms and approvals? Isn't this how we assure safety?" Well, no, it isn't. It's just a way of wasting time without adding any assurance at all. If you want assurance you need tests, not forms.
But you can accomplish something by having loads of bureaucracy keeping anything good from happening, which is that the only engineers who will stay in your company are the ones who can't get a job with a better run company where the work is more fun.
"Isn't deploying new software three times a day risky?" — no, if you have proper tests, it's far less risky. Every increment of change is small, every increment is carefully tested. If something goes wrong, people remember what change caused the problem quickly.
If you think it's impossible to do, then you should focus on why you think that. If something is painful, like doing software releases, it probably means you don't do them often enough to have fully automated the entire process.
In general, anything you're afraid of that causes pain is something you should be doing as often as possible until it stops being scary and stops causing pain. The usual bureaucratic impulse is the opposite, of course. It's to reduce the cadence until improvement is impossible.
