3 ms·

I've seen it suck even worse when trying to manage large X-Ops organizations. Something about the work, let's call it DevOps for the sake of simplicity, simply

I've seen it suck even worse when trying to manage large X-Ops organizations. Something about the work, let's call it DevOps for the sake of simplicity, simply does not seem to lend itself well to the scrum methodology. Often priorities will shift rapidly even during the course of 1 working day, issues are vaguely defined and poorly scoped by nature (AZ1 cannot reach AZ2, plz fix ASAP), and the work is extraordinarily hard to measure complexity/effort (a one line config change can take weeks of investigation and touch tons of services). I've seen plenty of people try though, to varying degrees of unsuccess. A kanban style system has always worked better for me personally.

simonjgreen 3y ago
See this all the time. There is a huge distinction between teams that are oriented to be proactively planned and teams that are oriented to be reactive. Neither is bad and both need to exist. Things will break people will have to fix them and therefore reactive work will exist.
- JohnMakin 3y ago
  I've seen this handled in various ways. Usually, the scrum master/PM will set aside extra "bandwidth" during a period that is expected to be heavy in interruptions. However, getting that right is almost impossible, and you can easily end up with way too much work in a sprint or way too little.
- freedomben 3y ago
  Yes, exactly! In my career I am usually the first ops/DevOps person on the team. These are usually startups who have been run by developers. Nothing wrong with that, I've spent most of my career as a developer. But there is typically a huge blind spot with developers when it comes to ops. That could be a whole blog post and will someday, but relevant here is that they often do not understand when I try to explain how poorly scrum fits with ops. It can be remarkably frustrating for both parties to discuss how to plan ops work. Even breaking the work down can be a battle. Traditional software developers like to push for little chunks of work broken down into tiny pieces. However, when you are talking about a task that is completely and utterly unknown, and could take weeks to result in a one or two line config change, it cannot be broken down without visiting the future, finding out everything we don't know yet, and returning and planning it meticulously. Unfortunately, we don't have that time machine yet
  - JohnMakin 3y ago
    This brings flashbacks of so many conversations I've had with scrum masters during kickoff meetings - "Estimate how many points this story has?" "Depends on if I figure out the answer in 20 minutes or 20 days"
dijit 3y ago
DevOps is definitely my favourite, since the history involved here is on the nose. For those not in the know, "DevOps Days" was the conference that intended to deliver Agile to Systems Administration. The job title that was supposed to come from it was Agile Systems Administrator... Alas, people got the conference conflated with the "10+ Deploys a day" talk from Flickr which merged ops and dev, and a mythology was born where everyone has their own interpretation of what devops means. :)
liveoneggs 3y ago
Operations is operations and fits well into the kanban system. Business operations should consider embracing kanban. Work comes in, work goes out, repeat. Scrum (with sprints and things) should exclusively be used for New Product Development and Pre-Launch iterations. Using it for operations/ongoing work/enhancements is broken from the start. "Waterfall" as defined by these articles is mostly a strawman. Standups only work if someone is in-charge enough to keep them on track.

simonjgreen 3y ago

See this all the time. There is a huge distinction between teams that are oriented to be proactively planned and teams that are oriented to be reactive. Neither is bad and both need to exist. Things will break people will have to fix them and therefore reactive work will exist.

JohnMakin 3y ago
I've seen this handled in various ways. Usually, the scrum master/PM will set aside extra "bandwidth" during a period that is expected to be heavy in interruptions. However, getting that right is almost impossible, and you can easily end up with way too much work in a sprint or way too little.
freedomben 3y ago
Yes, exactly! In my career I am usually the first ops/DevOps person on the team. These are usually startups who have been run by developers. Nothing wrong with that, I've spent most of my career as a developer. But there is typically a huge blind spot with developers when it comes to ops. That could be a whole blog post and will someday, but relevant here is that they often do not understand when I try to explain how poorly scrum fits with ops. It can be remarkably frustrating for both parties to discuss how to plan ops work. Even breaking the work down can be a battle. Traditional software developers like to push for little chunks of work broken down into tiny pieces. However, when you are talking about a task that is completely and utterly unknown, and could take weeks to result in a one or two line config change, it cannot be broken down without visiting the future, finding out everything we don't know yet, and returning and planning it meticulously. Unfortunately, we don't have that time machine yet
- JohnMakin 3y ago
  This brings flashbacks of so many conversations I've had with scrum masters during kickoff meetings - "Estimate how many points this story has?" "Depends on if I figure out the answer in 20 minutes or 20 days"

dijit 3y ago

DevOps is definitely my favourite, since the history involved here is on the nose. For those not in the know, "DevOps Days" was the conference that intended to deliver Agile to Systems Administration. The job title that was supposed to come from it was Agile Systems Administrator... Alas, people got the conference conflated with the "10+ Deploys a day" talk from Flickr which merged ops and dev, and a mythology was born where everyone has their own interpretation of what devops means. :)

liveoneggs 3y ago

Operations is operations and fits well into the kanban system. Business operations should consider embracing kanban. Work comes in, work goes out, repeat. Scrum (with sprints and things) should exclusively be used for New Product Development and Pre-Launch iterations. Using it for operations/ongoing work/enhancements is broken from the start. "Waterfall" as defined by these articles is mostly a strawman. Standups only work if someone is in-charge enough to keep them on track.