50 Shades of Gray - Are Standups Good or Not

03 Oct 21 16:29
2 minutes read

I’ve noticed that there are a few articles arguing about how useful standups are or aren’t on a day by day basis, making it a pretty white or black decision. However I think the situation is a bit more complicated than that.

To make it clear, I 100% agree that if your standup is just a quick recap of Alex is working on feature X and Bob the sailor man is working on feature Y, tasks that are clearly in your task management system then it brings 0 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.

    That being said, isn’t it possible to isolate projects better, get the teams smaller, and then have a tiny 3-5 man team in each timezone (+/- 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 you might ask ? Because it’s good to just have engineers stay together for a few minutes, rant off about what they’re bothered about and increase a bit the team coesion. 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.

    Reason is that the bigger the project, and the varied the feature set, there just might be things that fell between the cracks, and that’s normal, there’s no magical fix it button for a system.

    That being said, a quick chat about an engineer’s issues with task in your sprint/kanbanboard/email list/cookie template might just remind somebody else in your team that:

    1. They worked on something similar before in the project
    2. They worked on something similar before in another company
    3. They might want to pair up, or offer to pair up since they know this is a really convulted 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 properly.

« Back to posts