6 ms·

DevOps as it has been implemented in tons of company is bs. Its like the "Agile" push that companies thought they could get by buying a tool, and changing noth

by mugsie 12y ago

DevOps as it has been implemented in tons of company is bs. Its like the "Agile" push that companies thought they could get by buying a tool, and changing nothing else (release schedules, feature based release dates etc). My favorite way of looking at it is simple - replace the word DevOps with empathy. That is the core of the idea, so lets try it - "Empathy Team", "Empathy Person", "Empathy Engineer". DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team.

smcl 12y ago
Obligatory quote echoing your final sentence, from the seminal DevOps thought leader Jon Hendren: "DevOps is mostly just a way of reorganizing all your nerds and making them talk to each other more"
VLM 12y ago
"replace the word DevOps with empathy" This scheme also works with diversity, quality, best practices, and change management.
- mugsie 12y ago
  Yup - it does. I just seem to prefer the empathy quote for some reason :)
  - mmatants 12y ago
    Empathy is the actual mechanism for how those other things (quality, etc) are achieved. Diversity helps empathy (represent the user and relate to them better).
    - VLM 12y ago
      Another way to extend the analogy is its a standard management technique when provided with something you don't want to do, set up an isolated team with no deliverables, no authority, and no direct reports. Ta Da we got us "quality" or "diversity" or "Dev Ops" and we didn't have to change anything.
- deleted 12y ago
  [deleted]
- serve_yay 12y ago
  I seriously can't figure out what the hell you guys are talking about.
mhurron 12y ago
> DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team. Most posters here don't seem to get it. Most replies appear to be the idea that DevOps means you fire your Ops people and the Developers do Ops previous job and their own Development job as well.
- icedchai 12y ago
  Or, in the small company case, you never hire any dedicated ops people to begin with. You have developers fighting fires all day, getting interrupted constantly, causing them to hate their jobs.
  - gibsonje 12y ago
    Small company. We don't have many problems. We have a couple pain points but we fix them over time. When hosts die, it generally doesn't mean anything. There's redundancy in all things. I don't find myself interrupted often. Previous job had a "Systems" team and a "Database" team. Both were just teams of obstructionists. "Oh you need something today? Well, if you get a jira ticket made I could look into getting the requirements written up sometime in the next 2 weeks, to get the work assigned out next month." Not saying that's the norm, but damn I hope I never experience that again.
    - gknoy 12y ago
      Both were just teams of obstructionists. "Oh you need something today? ... get a jira ticket made ... work assigned out next month." It is possible that you might have a different opinion of the situation if viewed from their perspective. It's likely not deliberate obstructionism, but rather them trying to triage the requests so that they can be most effective across all customers. (It's possible that your ops team did not adequately communicate this to you.) In my current job, I am the sole developer responsible for maintaining a certain set of our codebase. I have multiple internal customers, each of whom have separate (external) customer-facing needs. I have enough tickets created for three people working full time, so I am constantly having to triage which are the most important. Part of the solution to this was to have a proposed plan for when to work on things -- I can then say, "Thank you for this well thought out ticket. I will be able to work on that in June." The most important thing is that my users' opinion about the criticality of things does not always match the overall picture, and I am always having to choose which tickets to postpone.
exelius 12y ago
> DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team. DevOps is about not having separate dev and ops teams (or QA for that matter). It's about having one team that coordinates on implementing user stories and comes up with the right solutions. Some members of that team have certain skill sets - i.e. some are more ops focused and some are dev focused - but it's one team. It's about creating personal accountability; there's no more blindly assigning tickets to an offshore ops team and hoping it gets done right. If you're doing DevOps right, you developers and your operations people are on the same team, sit in the same area and attend the same scrums. DevOps means that instead of saying "Ok, my work is done, but the deployment scripts need to be updated so I'll create a ticket with the ops team and they'll get it done next week", you can say "Ok, my work is done, but the deployment scripts need to be updated and I don't know how to do that, so I'll assign it to Mike." The feedback can go the other way too - if an implementation of a feature is too cumbersome to deploy, the ops guys are in the scrum with the dev guys and can work on a better design together, up front.
- chatmasta 12y ago
  One good solution I've seen to this is a hybrid approach. QA was their own team, but sent a representative to each other team. That meant QA engineers had two scrums each morning -- one for the team they were assigned to, and one for QA as a whole. It worked very well. QA had their own processes that other teams didn't need to worry about, but QA also understood the needs of all other teams.
signal 12y ago
That's close, but still a problem. If you put change responsibility formally on the shoulders of a team or individual you're throwing them under the bus. It needs to be approached as a cross-functional team initiative (which is reproduced to scale out). A DevOps team might work if they're in a leadership position, but how does it work on the ground?

by mugsie 12y ago

smcl 12y ago

Obligatory quote echoing your final sentence, from the seminal DevOps thought leader Jon Hendren: "DevOps is mostly just a way of reorganizing all your nerds and making them talk to each other more"

VLM 12y ago

"replace the word DevOps with empathy" This scheme also works with diversity, quality, best practices, and change management.

mugsie 12y ago
Yup - it does. I just seem to prefer the empathy quote for some reason :)
- mmatants 12y ago
  Empathy is the actual mechanism for how those other things (quality, etc) are achieved. Diversity helps empathy (represent the user and relate to them better).
  - VLM 12y ago
    Another way to extend the analogy is its a standard management technique when provided with something you don't want to do, set up an isolated team with no deliverables, no authority, and no direct reports. Ta Da we got us "quality" or "diversity" or "Dev Ops" and we didn't have to change anything.
deleted 12y ago
[deleted]
serve_yay 12y ago
I seriously can't figure out what the hell you guys are talking about.

mhurron 12y ago

> DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team. Most posters here don't seem to get it. Most replies appear to be the idea that DevOps means you fire your Ops people and the Developers do Ops previous job and their own Development job as well.

icedchai 12y ago
Or, in the small company case, you never hire any dedicated ops people to begin with. You have developers fighting fires all day, getting interrupted constantly, causing them to hate their jobs.
- gibsonje 12y ago
  Small company. We don't have many problems. We have a couple pain points but we fix them over time. When hosts die, it generally doesn't mean anything. There's redundancy in all things. I don't find myself interrupted often. Previous job had a "Systems" team and a "Database" team. Both were just teams of obstructionists. "Oh you need something today? Well, if you get a jira ticket made I could look into getting the requirements written up sometime in the next 2 weeks, to get the work assigned out next month." Not saying that's the norm, but damn I hope I never experience that again.
  - gknoy 12y ago
    Both were just teams of obstructionists. "Oh you need something today? ... get a jira ticket made ... work assigned out next month." It is possible that you might have a different opinion of the situation if viewed from their perspective. It's likely not deliberate obstructionism, but rather them trying to triage the requests so that they can be most effective across all customers. (It's possible that your ops team did not adequately communicate this to you.) In my current job, I am the sole developer responsible for maintaining a certain set of our codebase. I have multiple internal customers, each of whom have separate (external) customer-facing needs. I have enough tickets created for three people working full time, so I am constantly having to triage which are the most important. Part of the solution to this was to have a proposed plan for when to work on things -- I can then say, "Thank you for this well thought out ticket. I will be able to work on that in June." The most important thing is that my users' opinion about the criticality of things does not always match the overall picture, and I am always having to choose which tickets to postpone.

exelius 12y ago

> DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team. DevOps is about not having separate dev and ops teams (or QA for that matter). It's about having one team that coordinates on implementing user stories and comes up with the right solutions. Some members of that team have certain skill sets - i.e. some are more ops focused and some are dev focused - but it's one team. It's about creating personal accountability; there's no more blindly assigning tickets to an offshore ops team and hoping it gets done right. If you're doing DevOps right, you developers and your operations people are on the same team, sit in the same area and attend the same scrums. DevOps means that instead of saying "Ok, my work is done, but the deployment scripts need to be updated so I'll create a ticket with the ops team and they'll get it done next week", you can say "Ok, my work is done, but the deployment scripts need to be updated and I don't know how to do that, so I'll assign it to Mike." The feedback can go the other way too - if an implementation of a feature is too cumbersome to deploy, the ops guys are in the scrum with the dev guys and can work on a better design together, up front.

chatmasta 12y ago
One good solution I've seen to this is a hybrid approach. QA was their own team, but sent a representative to each other team. That meant QA engineers had two scrums each morning -- one for the team they were assigned to, and one for QA as a whole. It worked very well. QA had their own processes that other teams didn't need to worry about, but QA also understood the needs of all other teams.

signal 12y ago

That's close, but still a problem. If you put change responsibility formally on the shoulders of a team or individual you're throwing them under the bus. It needs to be approached as a cross-functional team initiative (which is reproduced to scale out). A DevOps team might work if they're in a leadership position, but how does it work on the ground?