A few years ago, if you would have asked me to define DevOps, my answer would have sounded something like “Mumble mumble automation, mumble, automa...
For further actions, you may consider blocking this person and/or reporting abuse
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=...
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.
Link here.
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.
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.
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."
Great post!
Great article.
What about discipline in DevOps?
Not sure I understand the question. Is discipline needed? Yes, especially for "don't automate stupid processes".