> People usually reply there whenever they start working ... Honestly, the blockers bit was the only useful thing for most of us there
What kind of blockers were did you find appearing at the start of work for there to be usefulness derived?
I have only ever experienced blocking situations once I am well into the work. And, as tempting as it may be to take the rest of the day off so you have something to tell at the start of the next day, that's not exactly a realistic business practice. Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around.
Certainly blockers need to be communicated, but timing them with the start of work seems completely untenable. If they could be foreseen they wouldn't be blockers.
>> Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around.
You must not be working with micro-services then. It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question. Now obviously I am not sitting idle while blocked, but assuming that blocker will be removed by next morning seems quite unrealistic and rarely happens in my world.
> It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question.
Sure, but you are still unlikely to realize that you're blocked by that exactly at the start of your day. Once your blockage has been communicated, likely in the middle of your day, the state will remain until you are unblocked. There is no value in repeating every day that you're still waiting on Outside Vendor. The blocking state has been addressed. It is known that nothing will change until the state has changed.
And it is not like Outside Vendor can update you in an internal stand-up on why it is taking them so long, given that they won't be present, so you're not even getting that value out of bringing it up again.
It's not about being territorial, it's about ownership. I assume you work for a small company. At Big Co. there are thousands of services and APIs. You can't give default permissions to everybody to call every API. That would be a giant security lapse. Other teams let you modify their code but only after they thoroughly understand what you need to modify and what is it that that you are tying to do. They own the code and run in production. So it makes sense for them to critically evaluate whether you should be allowed to do what you are trying to do. All of that takes time and hence multi-day blocker.
Generally we don't go walking through other teams code bases unless we have to and we usually consult with the team before doing stuff. They just don't let their roadmap block our roadmap.
We don't use microservices. That helps a lot. We also have teams that manage infra. We do own the code we deploy but anyone can jump in and help if a fix is needed.
Oh day to day blockers, especially when working on multiple things in parallel and you wait on someone else for some tasks. From our logs, some of our last few blockers were:
1) Waiting for someone review and merge a pull request so something else that depends on that can be sent for a release.
2) Some architectural code changes that needed to be discussed with the person responsible for the module before i go ahead with the implementation.
3) Someone waiting on me to finish the CI setup so they can deploy their project
4) Us waiting on external client for more input, so our CEO can go nag them for more requirement updates.
5) Me hoping the someone can fix the frontend code because i was frustrated with my (lack of) CSS knowledge the previous day...
None of those will come up at the beginning of the day. They are impediments that will only be revealed during the course of the work. Are people refraining from sharing important knowledge as it comes available so that they can grasp at something to share the next day, perhaps because reciting "no blockers" each day grows incredibly tiring? If so, how is that beneficial to the team being left in the dark for longer than necessary?
I've worked under that "today/tomorrow/blockers" regime before and never once, in the years we labored under it, did anybody report a single blocker besides "my computer crashed, waiting for IT to fix it".
What kind of blockers were did you find appearing at the start of work for there to be usefulness derived?
I have only ever experienced blocking situations once I am well into the work. And, as tempting as it may be to take the rest of the day off so you have something to tell at the start of the next day, that's not exactly a realistic business practice. Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around.
Certainly blockers need to be communicated, but timing them with the start of work seems completely untenable. If they could be foreseen they wouldn't be blockers.