They were talking about a DevOps manifesto at DevOpsDays Hamburg and it got me to thinking, what’s wrong with the existing agile development manifesto? Can’t we largely uptake that as a unifying guiding principle?
Go read the top level of the Agile Software Development Manifesto. What does this look like, if you look at it from a systems point of view instead of a pure code developer point of view? An attempt:
DevOps Manifesto
We are uncovering better ways of running
systems by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes over tools
Working systems over comprehensive documentation
Customer and developer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
That’s not very different. It seems to me that some of the clauses we can accept without reservation. As a systems guy I do get nervous about individuals and interactions over processes and tools (does that promote the cowboy mentality?) – but it’s not to say that automation and tooling is bad, in fact it’s necessary (look at agile software development practices, there’s clearly processes and tools) but that the people involved should always be the primary concern. IMO this top level agile call to arms has nothing to do with dev or ops or biz, it’s a general template for collaboration. And how “DevOps” is it to have a different rallying point for ops vs dev? Hint: not very.
Then you have the Twelve Principles of Agile Software. Still very high level, but here’s where I think we start having a lot of more unique concerns outside the existing list. Let me take a shot:
Principles Behind the DevOps Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable functionality. (more general than “software”.)
Software functionality can only be realized by the
customer when it is delivered to them by sound systems.
Nonfunctional requirements are as important as
desired functionality to the user’s outcome. (New: why systems are important.)
Infrastructure is code, and should be developed
and managed as such. (New.)
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage. (Identical.)
Deliver working functionality frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. (software->functionality)
Business people, operations, and developers must work
together daily throughout the project. (Add operations.)
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. (Identical.)
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. (Identical.)
Working software successfully delivered by sound systems
is the primary measure of progress. (Add systems.)
Agile processes promote sustainable development.
The sponsors, developers, operations, and users should be able
to maintain a constant pace indefinitely. (Add operations.)
Continuous attention to technical excellence
and good design enhances agility. (Identical.)
Simplicity–the art of maximizing the amount
of work not done–is essential. (Identical – KISS principle.)
The best architectures, requirements, and designs
emerge from self-organizing teams. (Identical.)
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. (Identical.)
That’s a minimalist set.
Does this sound like it’s putting software first still? Yes. That’s desirable. Systems are there to convey software functionality to a user, they have no value in and of themselves. I say this as a systems guy. However, I did change “software” to “functionality” in several places – using systems and stock software (open source, COTS, etc.) you can deliver valuable functionality to a user without your team writing lines of code.
Anyway, I like the notional approach of inserting ourselves into the existing agile process as opposed to some random external “devops manifesto” that ends up begging a lot of the questions the original agile manifesto answers already (like “What about the business?”). I think one of the main points of DevOps is simply that “Hey, the concepts behind agile are sound, but y’all forgot to include us Ops folks in the collaboration – understandable because 10 years ago most apps were desktop software, but now that many (most?) are services, we’re an integral part of creating and delivering the app.”
Thoughts?
the agile admin 
I have mixed feelings.
All manifestos are marketing documents.
All of them.
Agile is a shadow of what it should be, mostly because Agile in practice has disconnected from those principles.
So I guess I have a few questions:
why does devops need a manifesto? to advertise what? to who?
http://arxta.org/
If I find some time I’ll try to blog about it.
It’s a guiding vision. Sure, you *can* start using it as just a marketing term, and that’s when you lose your way. But you don’t have to. I think it’s less for marketing than for guidance (and many still do use agile in that way). It is also useful for marketing to devs and ops and, ideally, business in the same way that the agile manifesto marketed to just devs and business.
I can relate to your statement but I don’t agree with you. I think that agile manifesto isn`t primarily a marketing document . It’s up to you how do you implement agile methodology in your company. If companies practise agile in a different way this isn’t rooted in the formulation of the agile manifesto but in the understanding of the actors.
I’m working for a start-up, called Zenkit, which has developed a project management tool. My colleague Dinnie has recently published an article which helps to understand the agile manifesto.
https://blog.zenkit.com/uncovering-the-agile-manifesto-af9435cc4f00
Would really appreciate to hear your thoughts and feedback.
Marketing is an inevitable part of encouraging the adoption of new ideas. Sometimes people try to clean it up by calling it “evangelizing” when they are marketing to IT folks, but it’s really still marketing. If agile is an idea worth spreading, then somebody needs to be marketing it to do so.
But, that said, there are still ideas that sell themselves, and I think agile is one of them. It’s impossible to separate out the marketing from the idea itself in such cases; it’s all about how you use it.
Pingback: devopsdays in hamburg - Soenke Ruempler
Will agree with “working systems” over comprehensive documentation, I fear, as with agile that many people may take this to mean that documentation isn’t important and just won’t document at all. Often, people take priorities to mean that the lower priority is always trumped and that just isn’t true.
A friend of mine at a 14 person startup is feeling the pain of this now. As you grow, it takes more than just code to foster culture. Documentation is critical for meta data, decision justifications, architecture, and bootstrapping the usage of the automation and tools.
This got me thinking and writing: http://crunchtools.com/bootstrapping-and-rooting-documentation-part3/
Pingback: OCTO talks ! » Retour des DevOpsDays 2010 à Hambourg
Actually at the very first #devopsdays in Gent we agreed not to have a Manifesto .. the same discussion happened in Hamburg and again the end result was .. no manifesto …
Yeah… The more I see the DevOps movement pussyfoot around about defining anything, the more I am concerned that it won’t actually make sufficient inroads into fixing anything for most people. If the best we can do to those who are interested in the concept is say “You know… DevOps… It’s CULTURE! . And do Lean or something!” we are not helping anyone. We have come across a new, powerful way of changing how we do business, and just doing Marty McFly-style hand-wringing or engaging in morbid self-flagellation about putting the word “DevOps” on anything is us willfully fucking that up. In my not so humble opinion.
I’m a little cross after DevOpsDays Silicon Valley this year, where despite swelling interest in DevOps, we still have few (except for paid consultants) willing to not shilly-shally around and be embarrassed by the very word DevOps. When someone approaches us and says “Hey, there seems to be something there really working for you… How does DevOps work again?” there’s nothing wrong with having an answer – possibly incomplete or not 100% correct, but sacking up and having an answer (besides “well go read Deming and you’ll figure it out eventually…).
One of the key principles behind DevOps, in my mind, is sharing and not hoarding of domain specific knowledge, and this cussed refusal to come up with coherent definitions or reasonably agreed best practices to communicate to people smells of elitism and keeping the knowledge inside the DevOps Illuminati – I understand that’s probably not the intent, it’s more like overblown humility, but still.
Sorry, not mad at you specifically, but I am very frustrated on this general topic after the last DoD. This got long, I should probably turn it into a post of its own.
Oh, I just ran across this cool “Manifesto for 21st Century IT ” that incorporates a lot of the new thinking: http://blog.ingineering.it/post/39385342347/21st-century-it-manifesto
http://blog.ingineering.it/post/39385342347/21st-century-it-manifesto is no longer 😦
Pingback: Agile Austin – What Is DevOps?
Pingback: Why isn’t there a “DevOps Framework” / Manifesto? | DevOpsGuys
“The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. (Identical.)”
This part is BS. DevOps requires coordinating not only physical teams but virtual teams as well. DevOps is round the clock, international, and actually hampered by too much physical togetherness. There are successful companies that don’t chain themselves to the “face-to-face” nonsense.
Face-to-face, butt-in-seats, loud primary colors in fishbowl offices is so 1960s. This is the 21st century, lets act like it.
Pingback: DevOps Teams - Establishing a DevOps Team - Musing Mashup
Pingback: Water Cooler Web Dev Talk – Show #12 | Rob Simpson
Pingback: DevOps Practices | IT Pro Guy & Tesar.info
Simply speaking, what we are talking about here is a a collaborative work environment with pragmatic controls. DevOps is an attempt to give this simple notion a fancy name ..
Pingback: DevOps: What does this term mean and why should we care? – Jean-Christophe Huc («Jay C») – Chief Technology Officer
I’d prefer to have the DevOps Manifesto mention some specific DevOps practices. Here is my version. 🙂
[Ed: I like it, but comments aren’t the place for full blog posts – publish your own post and I’ll link to it!]