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:
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.”