QuestionWhat are the migration milestones in building out a DevOps group?
I suggest that this question be reframed a bit. For an organization to enter the world of DevOps means that one must adopt a mindset that is focused on agility in the processes and the methods used to execute those processes. It is very important that you identify the best way of carrying out that mindset across your organization and that it include not only software engineering, but also the customer, the business folks, quality engineering, test automation, release management, security, operations, system administration, etc. DevOps is about a fundamental reorientation to provide software in a more effective manner beginning with design and going all the way to production deployment.
Remember SOA?I will draw an analogy here to a recent trend in software architecture. The concept of a service-oriented architecture (SOA) embodies a set of principles for designing and developing software. It's the 'why', not the 'how' of software architecture (i.e., SOA is a means to an end, not an end in itself). Numerous vendors took the SOA term and twisted this notion into a wrong-headed marketing message that basically said, 'Buy our software and you will be doing SOA'. I spent a lot of time dispelling this myth over the last several years, encountering much resistance along the way. But make no mistake, SOA is not a technology problem.
If someone asked me about forming a SOA group inside their company, I would tell them that they already have one and it encompasses the customer, the software architects, the software engineers, the quality engineers, the release engineers, the security experts, and the operations folks. There is no need to assemble a brand new group. Would you advocate the formation of an agile group inside a company? I certainly would not because interpreting a methodology in such a literal fashion seems to me like you are already driving the car into the ditch and through the corn field. When I was a kid I learned a term for stuff like this, an Arkansas screwdriver (also known as a hammer). Just because you can doesn't mean you should.
Over the years, I have worked with many companies to get them on the road toward designing applications by using SOA. When I do this, I lead the customer toward the identification of folks across the organization who can participate in this effort. I was certainly not alone in this effort and this style as there are many others doing the same/similar thing. Although we operated on the idea that we were coaching customers to develop apps using SOA via agile methodologies, I now realize that we were also already leaning toward DevOps. (Based on my research, this is really how the DevOps movement came to be what it is today.)
A Perfect MatchGetting back to the original question, I would not approach DevOps any differently than I have approached the coaching of customers into the use of agile methodologies. Continue to coach customers in this manner and you will be successful. Only now, we have even more information and wisdom telling us that this is not just for software engineers. This is a fundamental change for an organization and should be broken down as described on the Agile Admin blog like so:
- Agile principles: The core values that form the agile movement (see the Agile Manifesto)
- Agile methods: Methodologies for running an agile approach including Kanban, Lean, SCRUM, XP, etc.
- Agile practices: Procedures for executing an agile methodology including Acceptance Testing, BDD, TDD, User Stories, Continuous Integration, Continuous Deployment, Daily Meetings (aka Standup Meetings), etc. etc.
The Value of DevOps to the BusinessFinally, the value of DevOps to the business is often misunderstood or not understood at all. Historically, the business side has treated software development as someone else's problem. The perception has often been that the propeller heads down the hall are responsible for the software, not the business side. This has always struck me as terribly short-sighted, especially for a company that would not make money without its software.
Consider another analogy here to depict this situation appropriately. Businesses love to equate themselves to sports teams and I've heard this one before, so I'll use the idea of a pro cycling race team (please forgive my cycling fever during this Tour de France season). A pro cycling team operates in a smooth, fluid manner handling anomalies as they arise without disruption. Like any good team it has the following characteristics:
- A clear direction with clear support and resources from the business side
- Team members have a good relationship with one another and with supporting companies or organizations
- The team monitors many external factors that effect their performance and their success
A company that relies on its software to make money is very much the same. Consider the following comparisons:
- Just as a pro cycling team has a clearly defined direction, so should a company that relies upon software. This message needs to be tuned appropriately to fit different areas of the business, but the overarching message remains – create a machine to make money.
- Just as a pro cycling team has clear support from the business side to stay on top of the technology in its field, so should a company that relies upon software. This means that time must be dedicated to the craft of building software, continued education where necessary, the purchase of materials (books, publications, etc.) and tools, etc. Do you want excellent, highly talented mechanics, masseuses and domestiques or just mediocre ones?
- Just as a pro cycling team forms close relationships between team members, so should a company that relies upon software. This doesn't just apply to folks who work in the same department. The most important relationships are those that span boundaries and break down barriers between departments within an organization.
- Just as a pro cycling team learns to execute flawlessly together, so should a company that relies upon software. Consider that the software a business relies upon to make money is the bike and the rider that a pro cycling team chooses. Do you think that the pro cycling team just arbitrarily decides how to prepare and train for events? Or do you think the pro cycling team has a strict, regimented formula to its training and preparation? A business that relies upon software to make money should also have a strict, regimented formula for crafting, testing, deploying and supporting it's software. Without this level of capability, the ability of the business to make money on a consistent basis is hamstrung by its own processes or lack thereof.