A few years ago I wrote a brief post about committed stand-ups in which I drew on the work of Jonathan Rasmusson and posed the following questions:
How effective is your daily stand-up meeting?
Is it energising the team or does it have a “going through the motions” feel to it?
Part of Jonathan’s answer was to, rather than simply let the team know what you plan to do today, tell them “how you are going to crush it today”.
The change of emphasis that Jonathan suggested can only work if individuals in the team genuinely feel like “crushing it” for the sake of the team. Unsurprisingly, barriers can exist which prevent effective stand-ups.
The reason for standing up whilst meeting is to keep the discussion short and to the point. If the meeting drags on for too long, participants are likely to become distracted. Obviously, the larger the team, the harder it is going to be to enable each member of the team to focus on what others are saying.
In my view, any more than about six people in a standup reduces its effectiveness.
Good stand-ups typically involve participants who are all working on the same project. If someone else in the stand-up starts talking about an activity that is unrelated to what the another in the group is doing, it is only natural that the listener will be inclined to tune out.
Stand-ups can become less effective if always led by a manager. In my experience, they work better if the role of convening the stand-up is shared throughout the team.
Whilst stand-ups can effectively include remote participants, of course they will break down if the technology fails. When this happens, those that are remote can be left laughing or thinking, “what was the point of that?”
In my experience, the most effective stand-ups have been in small teams focussed on the same project.
I recall that during my early experiences of eXtreme Programming in about 2001, the Daily Stand-up practice was one of those that I found most effective. In my view, it can still be very valuable, provided barriers aren’t inadvertently put in its way.
Previous post: On Test Driven Development
More recently: Stress and Software Development
© 2023 Keith Pitty, all rights reserved.