Daily Standup Meetings: Anti-patterns And What to Do About Them

Leider ist der Eintrag nur auf English verfügbar.

Daily standup meetings are a mainstay of agile software development methods, such as XP, Kanban (which used to be an inventory control system having originated at Toyota) and Scrum, of course.

Given that agile development methods are by far the most dominant ones in the software industry today, it should come as no surprise that daily standup meetings are a common feature of software development processes these days.

These meetings basically serve the purpose of informing everyone on the team about these 3 aspects in a timely manner:

1. What did I do yesterday?
2. What am I going to do today?
3. What obstacle – if any – did I encounter?

This allows the team members to help each other, fosters communication and helps surfacing problems and impediments at an early stage so those can hopefully be eliminated without losing too much time. This last point is vital especially when comparing agile processes with traditional ones like Waterfall because with the latter kind of project management issues and delays typically only crop up at the end of a software project or project phase, which in turn can lead to huge delays and an equally huge increase in costs.

While undoubtedly useful and even essential to modern software development, standup meetings can devolve into less effective or even detrimental affairs if one isn’t careful about sticking to their true purpose. This is especially true in larger organisations, particularly those which previously were organised along more rigid structures. In these cases standup meetings can display certain anti-patterns that not only fail to comply with the actual goals of standup meetings but can even keep the participants from accomplishing work instead of facilitating progress.

Software Engineer and YC alumni Yan Lhert recently has published an interesting article about the most frequent of
these standup antipatterns including suggestions for possible remedies and fixes for each of them.

If you’re member of an agile software development team or help such teams to work more efficiently and effectively, this article is very much worth reading.