Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Though I mostly agree, I'd step back a bit and say step 1 definitely matters. Goin' Kanban is a good thing but it might not be the second important thing on your list, same as automation (even if it is extremely relevant and possibly can't be stressed enough either).
At the bottom, however, personal experience: Question organizational "walls". In quite a few approaches so far I have seen people considering DevOps to be something forcing "Ops" people to change their behaviour so to be more effective. But seeing one is trying to go *Dev*Ops makes it rather obvious there's "Dev" in this organizational context too. If there's "Dev", there is also very likely to be some product responsibility, someone in charge to do development planning and to earn money with whatever Dev and Ops do.
For me, the important thing about DevOps is and always has been that these folks - Development, Operations and "Product" people - do need to be aware that they do have a shared interest in earning money with a product. That's not just development, it's also not just operations, it's not just planning -- it's rather all these things put together. In some way this is where the "error budget" idea outlined in the Google SRE book jumps in:
This idea only works if the "product" person knows enough about the operation issues of the system (s)he's in charge for, too - downtimes, bottlenecks, required administration effort, ... .
This idea, too, only works if (talking agile development) a dev team is aware of operational issues and has a Definition Of Done that includes operation non-functional requirements as well. Maintainability needs to be first-class citizen in each software component built, but this doesn't happen out of the blue.
By now, most of these things (still) are sort of isolated: Product planning very often happens in (best case) in a customer-driven echo chamber where operation issues aren't of much relevance. Development is in a process to quickly work through this product planning and strategy, doing agile implementations of user stories and isn't really aware of operations issues. And operations, at the end of that line, is supposed to do effective maintaineance of all this in a production environment. Getting operations feedback and requirements back into the product development cycle and getting development, operations and planning people to speak to each other in a structured and planned way should be way up your priorities list. ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Though I mostly agree, I'd step back a bit and say step 1 definitely matters. Goin' Kanban is a good thing but it might not be the second important thing on your list, same as automation (even if it is extremely relevant and possibly can't be stressed enough either).
At the bottom, however, personal experience: Question organizational "walls". In quite a few approaches so far I have seen people considering DevOps to be something forcing "Ops" people to change their behaviour so to be more effective. But seeing one is trying to go *Dev*Ops makes it rather obvious there's "Dev" in this organizational context too. If there's "Dev", there is also very likely to be some product responsibility, someone in charge to do development planning and to earn money with whatever Dev and Ops do.
For me, the important thing about DevOps is and always has been that these folks - Development, Operations and "Product" people - do need to be aware that they do have a shared interest in earning money with a product. That's not just development, it's also not just operations, it's not just planning -- it's rather all these things put together. In some way this is where the "error budget" idea outlined in the Google SRE book jumps in:
This idea only works if the "product" person knows enough about the operation issues of the system (s)he's in charge for, too - downtimes, bottlenecks, required administration effort, ... .
This idea, too, only works if (talking agile development) a dev team is aware of operational issues and has a Definition Of Done that includes operation non-functional requirements as well. Maintainability needs to be first-class citizen in each software component built, but this doesn't happen out of the blue.
By now, most of these things (still) are sort of isolated: Product planning very often happens in (best case) in a customer-driven echo chamber where operation issues aren't of much relevance. Development is in a process to quickly work through this product planning and strategy, doing agile implementations of user stories and isn't really aware of operations issues. And operations, at the end of that line, is supposed to do effective maintaineance of all this in a production environment. Getting operations feedback and requirements back into the product development cycle and getting development, operations and planning people to speak to each other in a structured and planned way should be way up your priorities list. ;)