I tend to agree with AnoE's answer. Getting the people and giving them the vision are primordial before DevOps should be put in the picture. I would also like to add two more things on top of that. The additions come from the experience with a team that got excited about "DevOps".
You already have the definition in mind, but I'd like to bring Wiki's:
DevOps (a clipped compound of "development" and "operations") is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.
In short:
- You want to build a team of developers, testers and operators
- Enforce short development cycles
- Enforce shorter deployment cycles
- Automate the above processes
- Due to the agility of the process, enforce monitoring and alerts at all stage of development (e.g. test, qa, production)
- You need a set of tools that will increase efficiency accross every stage (i.e. Jenkins, Jira, Gerrit, etc.)
With these in mind, I can now bring the points previously mentioned at the beginning.
Failing is good
A baby doesn't learn to walk by standing up and walking. He learns through constant tries and failures. Even if, for an unknown reason, he gets up and starts walking, we shouldn't expect our babies to achieve the same. I usually point that out when people compare themselves to Google, Amazon or any other company with great achievements. Their failures thought them how to get stronger more than ingenious ideas all the time. Right now for example I am improving my english through constant writing and failure to make my points clearer and clearer.
Failures will indicate your football team where improvement is required. These weaknesses will vary from a team to another. It might be in tooling, leadership, lack of vision, roadmap pressure, lack of experience, etc. No matter the reason, it is primordial that you take time to review each development cycle with everyone. Otherwise, you might enter the stage below, which is hell to come back from.
Always failing is not good
Something was wrong. Then something kept being wrong and that something got culturally accepted even though it is slowing down the team. Skipping failing tests, non automated provisionning management, deploying with crossed fingers are among few I had the chance to experience. These are triggers that indicates improvements are required. Failing to notice them can bring you to a hellish state where coming back will require a Genesis project.
My answer is basically, go ahead for all the pros. But be aware that this sort of process will require culture and team monitoring in the sense that when things start getting bad, your team must learn from it or it will die from it.
