Living document · revised as I learn
How this work goes well
The four values, with the twelve principles that go with them.
The 2001 Manifesto for Agile Software Development was written by people building software, and it shows. Most of it carries over to infrastructure work cleanly. Some of it does not, because we inherit systems we did not build, we cannot ship a broken increment and fix it Tuesday, and our users notice immediately when we are wrong.
So this is the version written for the work we actually do.
It is not binding on anyone, including my own team. It is a description of how I think this work goes well, written down so there is something concrete to agree with or argue against. I am publishing it in case it is useful to yours.
Part one
We are uncovering better ways of running the systems other people depend on, by doing it and by helping each other do it. Through this work we have come to value:
Shared knowledge over individual heroics
The person who can fix it alone at 2am is valuable. The team that never needed them to is more valuable. Every system one person can operate is an outage waiting for a vacation.
Systems that work over documents that describe them
A running service beats a beautiful design doc. But note where the line falls. A concise runbook someone else has successfully followed is part of a working system, not a description of one. It is the forty-page architecture document nobody has opened since the review that we are arguing against.
The customer's problem over the ticket boundary
We rarely talk to customers directly, and that is usually by design. The help desk does. So do the business analysts, the product owners, and whoever else in your org sits between the people who need something and the people who build it. They are the ones who hear from the customer, and they are our line of sight into what is actually happening out there.
Treat them as partners carrying real information, not as a queue that hands us work. When they tell us something is hurting, that is the customer talking.
Absorbing change over protecting the plan
Requirements move, hardware slips, funding shifts, and a vendor discontinues the thing we standardized on. A plan that cannot survive that was never a plan. It was a wish with dates on it.
That is: there is real value in the items on the right. Tools, documentation, agreements, and plans all matter, and most of ours should be better than they are. The left side wins when the two genuinely collide, which is less often than people reach for it.
Part two
Availability is the deliverable. The ticket, the document, the meeting, and the dashboard all exist to protect it. When one of them starts competing with it, the priority is not ambiguous.
Change is constant in infrastructure. The goal is not to prevent it but to make it survivable. Small and reversible beats large and careful.
Deliver improvements continuously rather than saving them for an event. A quarterly maintenance window is a batch, and batches hide risk until they release it all at once.
The people who run the system and the people who hear from the customer should be in regular contact. Not only during an outage. A standing conversation catches things a ticket never will.
Build the team around people who can be trusted with judgment. Then give them the context to exercise it. Context, not just permission.
The fastest way to move knowledge is a conversation. The most durable way is a runbook that someone other than its author has followed successfully.
No system should depend on one person being reachable. Single points of failure in people are the ones we tolerate longest and regret most.
Sustainable operations means a pace we could hold indefinitely. If someone is regularly rescuing us, that is a design defect, not a personality trait, and it belongs in the retrospective.
Attention to engineering quality is what buys future speed. Deferred maintenance is a loan, and the rate is variable.
Simplicity is mostly about doing less. The system we did not build cannot page us at 2am.
The best designs come from teams that plan together, not from whoever moved first. Speed at the start is usually borrowed from the middle.
Stop regularly, ask what is actually going wrong, then change exactly one thing. A retrospective that produces no change is a meeting about feelings.
About this
This is original writing, not a translation or adaptation of the 2001 Manifesto text. It borrows the structure of four values and twelve principles, which is an idea rather than a text. The original is one page, free, and worth reading first: agilemanifesto.org.