, 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.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Perry E. Metzger
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!