4 ms·

I was about to write that. This is very visible in operational teams. Depending on what is going on, an operational team will spend 20 - 40% of their time fire

by tetha 5y ago

I was about to write that. This is very visible in operational teams. Depending on what is going on, an operational team will spend 20 - 40% of their time firefighting or at tightening screws and oiling wheels - maintaining systems. Sometimes it's a good week and it's just 10%. Sometimes you launched a new product, and it's 60% because everything is failing. As a conclusion from there, it's not a good idea to schedule more than 50% - 60% of deliverables with deadlines, because the right outage is going to toss those estimates really quickly. That's in itself the definition of sufficient slack. If you don't have that, prod fails and no one is around to fix it. If you do, someone can usually start poking at it quickly.

antod 5y ago
Yup. I always liked to have my team (been in the infra/ops/sre/devops/sysadmin areas) focussed on latency rather than throughput by having slack. Luckily we've usually been able to avoid Scrum etc, and work in a way closer to Kanban. There have been times though (like right now sigh) where we're forced into a throughput oriented mode by commitments made elsewhere out of our control. It sucks, and we end up ignoring too much of the little stuff for long enough that they end up becoming fires you need to put out (is ops debt a thing?), your tooling and automation suffer, knowledge silos build up within the team, and the throughput will end up tanking anyway. I like to use 50% allocation on "project" work as a nice rule of thumb for reactive ops oriented teams. Any higher can only be sustained for short periods without negative effects. This article resonated with me pretty deeply.