Getting twice as much out of half as many stand-ups

We realised we needed to hit the reset button on the team and treat it as though a new team had just been formed (which essentially it had been). We sat down as a team and had a virtual retrospective on our ways of working - what processes had been working for us, and what were holding us back. One of the main highlights of that discussion was that stand-ups were highly ineffective - people were tuning out, the stand-ups were running over time, and it didn't leave us with a better idea of what the team's blockers were. We had tickets that had been sitting in "blocked" or "functional review" for several days with no updates. We had been approaching standup where everyone in the team had to give an update, and it was often people listing everything they'd done the day before so as to sound busy, rather than focusing on tickets or issues specific to the squad.

We decided to take a new approach whereby we would have one person share the Jira board and would stop at every in-progress ticket and ask where it was at. The first day we tried this approach was epic. Nearly all of the five stories in "blocked" were able to progress within 24 hours after everyone had a shared understanding of why they were blocked. The four tickets stuck in "functional review" were able to be moved to "done" on that day once we had a discussion around who needed to review them. Within a week, our cycle times were half of where they were at when we started Q3.

You might still be wondering about the "half as many stand-ups" part of the title. Well, after the main standup, we also had a follow-up standup for the backend engineers. This standup was set up so as to keep technical chat out of the main standup, where it might not be relevant to product/design members of the team. After observing this standup for a couple of weeks, we realised that it was not really a standup at all. What we really needed was a chance to huddle as engineers if someone was stuck on a technical issue or wanted some feedback on a technical approach. We kept the time in the diary, but changed the title of the meeting to "optional engineering huddle." This change meant that people wouldn't feel obligated to attend every day, but also ensured there was time set aside in the diary to ensure we would all be available for a huddle if we needed one.

These changes probably feel obvious and not very significant, but should serve as a reminder to us all that we need to continuously be critical of our ways of working and not just do things a certain way because we've always been doing them that way.