I’ve noticed that a few articles are arguing about how useful standups are or aren’t on a day-by-day basis, making it a white or black decision. But the situation is a bit more complicated than that.
To make it clear, I 100% agree that if your standup is a quick recap of Alex is working on feature X and Bob the sailor man is working on feature Y, tasks that are in your task management system then it brings zero value to the table.
But it doesn’t need to be that way and I’ll try being the devil’s advocate.
- You don’t need to do standups if your team/squad/cell/happy family is all spread across the world.
It should be possible to better isolate projects and have smaller 3–5-man team in each time zone (+/- 2 hours)
- Check a standup’s team composition, you might not need your managers.
Call them Morning Sunshine Chat, or Brainfart Session, or whatever name you want.
Why might you ask? Because it’s good to have engineers staying together for a few minutes, rant off about what they’re bothered about and increase the team cohesion. This might sound like a cliche (and it is) but for me, so far interaction with my fellow peers is high on my list of nice things to have.
- It might trigger some unexpected domain knowledge sessions:
Think of it this way, you might have a perfectly documented system with 100% test coverage and CI/CD, with updated 3’rd party components that magically don’t break anything, or you might admit you had a nice dream and wake up.
The reason is that the bigger the project, and the varied the feature set, there just might be things that fell between the cracks. That’s normal, there’s no magical fix-it button for a system.
A quick chat about an engineer’s issues with a task in your sprint/Kanban board/email list/cookie template might just remind somebody else in your team that:
- They worked on something similar before in the project
- They worked on something similar before in another company
- They might want to pair up or offer to pair up. The reason is since they know this is a convoluted piece of code in which 100% test coverage means nothing since you could introduce new exceptions that might or might not be covered by tests.
Top comments (0)