3 ms·

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

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"

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"