4 ms·
At large companies, I've always been in the habit of expecting one thing I need per quarter. That means that if I need something this quarter, I put it on the
by jrockway 5y ago
At large companies, I've always been in the habit of expecting one thing I need per quarter. That means that if I need something this quarter, I put it on the other team's roadmap for next quarter, and then do my integration the quarter after that. (My experience was an organization where OKRs were the root of all planning. If you are working with teams that do bug triage / prioritization / sprint planning every two weeks, then obviously the latency can be decreased. But quarters seem like an artificial boundary that people love for whatever reason.)
This sounds terrible, but it worked pretty well for larger things. I was a TL and was in the habit of meeting with my internal customers before quarterly planning, to make sure that we could add their requests to our todos for that quarter, and then make sure we always executed on them. (We did do the things we promised, so people could make accurate plans. I remember many quarters of people sounding mildly shocked that we did stuff they asked for, but after a track record of execution, we got trust without any pushback like "can you do that right now instead of next quarter?")
Obviously, this doesn't help you very much if you want to get your thing done today and move on to your next task. Your product and your integration is going to look like the org structure that your company has. If you need deep integration with the product but are a separate team, well, I've simply never seen that work. The teams need to be much closer together in the org for that to happen.
Edit: oh, I'll add one other thing. Once planning starts to work, you can kind of dial up or dial back how quickly you want to react to one-off tasks or special requests. For example, if your team has a track record of completing 100 story points worth of work per sprint, you could only take on 80 story points and use that capacity for special requests. Planning sounds like a drag, but the discipline is actually very useful.