3 ms·
The article is talking about throughput not latency. There are not dates mentioned.
by flappyeagle 3y ago
The article is talking about throughput not latency. There are not dates mentioned.
- milesvp 3y agoForgive me. I thought I was being clear that I was talking about throughput. My team, when we started to get better at not overcommitting in any given period was able to produce more countable work. Not just more story points (inflation is super common) but more actual deliverables. It was weird, because we all felt like we were working less, we just thought we had to be honest about our commitments. But when you looked at the trend line at the end of the quarter, there was an increase in what we were able to do. I don’t claim to know why this works, but it’s such an old phenomenon that there are lots of sayings that hint at it. I know that when I’m personally not overcommitted I have more capacity to focus. When I have fewer things on my plate, I context switch less. But I think something else happens as well. When you say no to things, it forces others to be more deliberate with their asks. They stop asking for low value things.
- toss1 3y agoExcellent Seems likely that a big reason for the increase was unseen, but cumulatively huge. When everyone is not rushing so much, fewer interruptions happen. Each is tiny, but the cost of context switching is cumulative and even nonlinear. You're benefitting from bending that in the good direction - reducing thrashing.
- SketchySeaBeast 3y agoI'm on a 4 dev team (one of many). 3 of us commit to only do what we are pretty sure we can do. One of our team commits to way more than they should. Guess which of us is always carrying over stories and whose new functionality creates new bugs ever sprint? They never can wrap stuff up completely, they are like a tar ball of chaos. Unfortunately they are supposed to be our tech lead so all we can do is shake our head and watch.