3 ms·

I understand their position, I recently had a chat with a guy in DevOps, I'd made a request I knew would take at most, 5 minutes. He said he'd try to get to it

I understand their position, I recently had a chat with a guy in DevOps, I'd made a request I knew would take at most, 5 minutes. He said he'd try to get to it by the end of the week. That would potentially have caused my story to carry over to the next week. I opened a Teams chat and asked about it. He said his manager told them to manage expectations. He said he'd cut me a break since I was technical and would understand and got it done in 2 minutes.

WendyTheWillow 3y ago
A classic book called The Phoenix Project talks about ways to manage this. If I recall correctly, teams can fall into a vicious cycle where they only respond to immediate problems and, therefore, cannot schedule and prioritize their work. By maintaining a work backlog that gets prioritized and saying no to everything else, the team can ensure their work capacity gets respected and not get flooded with more than they can handle. So, in this way, your DevOps coworker is right. However, I don't think it's true when a team isn't at capacity, which is the scenario I envisioned when I replied. In the case where it costs little to nothing to quickly meet another team's request, the mature thing, IMO, would be to either a) do that thing or at least b) engage in good faith to put the task into your work backlog and prioritize it based on the larger impact of the overall project to the company as a whole. When a team isn't at capacity, the work would be done immediately while simultaneously reinforcing the value of the process to protect your work capacity and prioritization ability. Everybody wins. I suppose this is what I mean by "maturity"; teams have established processes to protect the team, but if the process allows for additional work, it's maladaptive to gum up the works just to keep expectations low. ...but that response is the "full PM" treatment; that's what I'd tell my boss or answer in an interview. In reality, I think of process as a "backstop" of sorts. You invoke process only when you're reaching some kind of capacity or limitation. If it's no sweat, just do it.
- reactordev 3y ago
  This is the way. If you aren’t at capacity then the manager can step in and say “yeah, we can do that, let me get a ticket/issue/record of it so we can track it” and then proceed to work on it. This works in Kanban really well. If you are at capacity or have planned a sprint already and are midway through the run, it’s ok to say no and get it prioritized in the backlog. If you’re DevOps and the Ops part of the role requires you to respond to tickets in a timely manner then this breaks down. What we are saying though is that having a plan is a good thing. Protecting the plan is a good thing. Adopting work and helping others is a good thing. The work being adopted needs to be planned and prioritized though. If it’s a small task (like the OP said, it was a 5 minute thing) than opening a chat with them about it after creating the necessary record is fine. The fact they agreed (regardless of classification that they were technical so they would understand) shows there’s hope in your org for empathy. What you shouldn’t do is say no to adopting the work while you sit back and play wordle until you feel the person has waited the necessary amount of time. Also, don’t write systems that require 14 approvals and a shaman and waiting 48 hours for a status change before you can begin work.

WendyTheWillow 3y ago

A classic book called The Phoenix Project talks about ways to manage this. If I recall correctly, teams can fall into a vicious cycle where they only respond to immediate problems and, therefore, cannot schedule and prioritize their work. By maintaining a work backlog that gets prioritized and saying no to everything else, the team can ensure their work capacity gets respected and not get flooded with more than they can handle. So, in this way, your DevOps coworker is right. However, I don't think it's true when a team isn't at capacity, which is the scenario I envisioned when I replied. In the case where it costs little to nothing to quickly meet another team's request, the mature thing, IMO, would be to either a) do that thing or at least b) engage in good faith to put the task into your work backlog and prioritize it based on the larger impact of the overall project to the company as a whole. When a team isn't at capacity, the work would be done immediately while simultaneously reinforcing the value of the process to protect your work capacity and prioritization ability. Everybody wins. I suppose this is what I mean by "maturity"; teams have established processes to protect the team, but if the process allows for additional work, it's maladaptive to gum up the works just to keep expectations low. ...but that response is the "full PM" treatment; that's what I'd tell my boss or answer in an interview. In reality, I think of process as a "backstop" of sorts. You invoke process only when you're reaching some kind of capacity or limitation. If it's no sweat, just do it.

reactordev 3y ago
This is the way. If you aren’t at capacity then the manager can step in and say “yeah, we can do that, let me get a ticket/issue/record of it so we can track it” and then proceed to work on it. This works in Kanban really well. If you are at capacity or have planned a sprint already and are midway through the run, it’s ok to say no and get it prioritized in the backlog. If you’re DevOps and the Ops part of the role requires you to respond to tickets in a timely manner then this breaks down. What we are saying though is that having a plan is a good thing. Protecting the plan is a good thing. Adopting work and helping others is a good thing. The work being adopted needs to be planned and prioritized though. If it’s a small task (like the OP said, it was a 5 minute thing) than opening a chat with them about it after creating the necessary record is fine. The fact they agreed (regardless of classification that they were technical so they would understand) shows there’s hope in your org for empathy. What you shouldn’t do is say no to adopting the work while you sit back and play wordle until you feel the person has waited the necessary amount of time. Also, don’t write systems that require 14 approvals and a shaman and waiting 48 hours for a status change before you can begin work.