DevOps is gimped cybernetics and systems theory. Richard Hamming has a great set of lectures on how to build software systems and what questions to ask while building such systems.
He keeps driving the point that you can't take manual processes and make them faster with automation. You need to re-think how the entire pipeline/system works to truly benefit from computers and automation.
I love that formulation of DevOps. It strikes me as a dead on diagnosis of the shortcomings and disorganization of DevOps, but simultaneously a valuable pointer towards the great potential as we work out solutions in this problem space.
Your second point seems to be a corollary of Conway's maxim "that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations." Is this part of the series of lectures you referred to? youtube.com/watch?v=5vQ4CekU6sg&t=...
Yup. That's the one.
For the organization trying to change their culture, the GROWS method gives a loose formula. The first step is to get buy in from everyone in the org that this will be painful in the moment but better in the long run. If you attempt to become. "cloud-native" without cultural changes you will suffer like IBM is.
Great points. I wrote an article that echoes this using system dynamics and the impact to service rates. The tl;dr version is - switching from functional work design and technical depth in a few areas to a horizontal work design that requires technical depth in many areas has a very high chance of setting you back. Get the people and process thing figured out first.
Good post. Completely agree that DevOps is simply agile development, with the proper emphasis on the disciplined lean engineering practices - rather than the shiny bells and whistles that tools have. In that sense DevOps is just a new term to describe Agile since "Agile" was unfortunately co-opted by the consultants and vendors. I expect that within a few years the term DevOps will be so over used and adulterated that a new term will be needed again by the practitioners.
Also, I think that DevOps and Scrum have some fundamental compatibility issues. I highly recommend using Kanban and Continuous Delivery, rather than Scrum.
Good point with the communication. I am afraid it is not obvious for everyone - knowledge sharing. What is your suggestion to encourage guys to share? Some, I guess, are afraid of being .. replaced :)
Leading by example helps - documenting everything you work on and presenting overviews to the group when possible. Changes to on-call can help too. "If your stuff isn't documented, I'm going to call you instead of troubleshooting on my own."
What about discipline in DevOps?
Not sure I understand the question. Is discipline needed? Yes, especially for "don't automate stupid processes".
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.