1. 12
  1.  

  2. 3

    The pattern that stands to me from both this post and my experiences with bad, ugly, and good standup meetings is that if you’re not directly producing deliverables, you should not be in the standup meeting. It’s goal is to coordinate between the team, not do status report. If the manager/product owner/whatever wants status updates, get it elsewhere: JIRA, git, email, chat, smoke signal, whatever.

    1. 2

      My trick for making ‘Ugly’ standups productive: book the 15 minutes after the standup for optional deep-dives. If nothing comes up, people can reclaim the time. If something does come up, like the example of the architect and developer questions, then you can push it out of the standup without feeling like a valuable discussion is going to be lost.

      I always propose this in the ‘Ways of Working’ meeting for a new project, and quite a few people find it so effective that they take the practice into other teams. Not everyone is a fan, but you can usually get them to try it for a few sprints and take feedback in the retro on whether it is working. Usually within a sprint you’ll have a few examples of important questions that got immediate answers because of the time reservation, and the team and PM will want to keep it.

      I’d recommend reading the book “Mastering the Rockefeller Habits” by Verne Harnish, the section on organisational communication, so you can articulate the value very clearly: He makes excellent arguments for scheduling communication time for predictable issues, rather than trying to organise ad-hoc meetings. I’ve stolen those arguments to get Project Managers to buy in to this approach!

      1. 2

        Standups should be for things that require communication between people. Some examples:

        • blockers
        • reaching out for help
        • warning others about potential problems; surfacing info that would cost time or money if people didn’t know it
        • giving advance notice about major interface changes (API, REST, method signatures, DB schema, whatever)

        Telling 19 other engineers that you were editing module XYZ yesterday, when none of them have worked in that module in the last 3 months, nor will be in the next 3 months, is a waste of time. It does not involve more than one person.

        1. 1

          A 19 person team seems counterproductive already. I don’t think I’ve ever seen a team that big, let alone worked in one.