On standup meetings

It's time when groups of people instead of individuals create the majority of software systems. The IT industry has a bunch of approaches on how to organize the work of these groups. One of the youngest idea is Agile, which is implemented with frameworks like Scrum, Kanban and many of their adoptions. Most of them use a ceremony called a "standup meeting".

Preface

Some people have an opinion that standup meetings are not required at all. As far as I understand, their experience with highly mature, perfectly motivated teams with people perfectly understanding what their doing makes them think so. Unfortunately,  I rarely see such types of teams. Maybe, we should put effort into converting every team into a truly mature autonomous team. But while we do so, I still find stand up meetings useful: in my own experience it usually brings more order, than chaos.

Having said that, I see a lot of misconceptions and misunderstanding of those meetings. Weak managers made a lot of people think that standup ceremony is a status meeting. They use it to make every team member guilty: "what you were doing yesterday?" or "why you did so little".

In my opinion, which can differ from the scrum guide, standups are all about sharing information and revealing issues.

Let's look what we can discuss on these meetings.

Technical issues and blockers

The developers stumble upon technical problems all the time. It can be issues with github being unavailable, or lack of permission, or API inconsistencies. Usually, developers rise those issues right away in a slack channel or via e-mail, so the issue can be dealt with by the colleagues. But frequently the developers are just working on the problem they can't grok right away. A standup meeting provide a place where those problems can be shared: chances are somebody from the team have an idea or at least can help later.

Finished work

The pull request is the representation of the developers job. In my practice developers have a channel in the chat where they can share that a new pull request is ready for review, or even the github/gitlab/stash can send a notification about a new pull request. However, those messages are often ignored due to high amount of information. Standup is again a point where a necessity to review the PR can be shared.

Plans for the day

Productive people usually have some plan for the day. Developers are not the exclusion. They either have a task in progress, or have a list of tasks to pick from. Such plans can be shared on a standup. Of course, with a proper discipline this should be totally predictable from the task board: we should already have a prioritized list of tasks/stories. However there are always stories of pretty much the same priority, or the list is not properly prioritized. Or some bugs are found from the previous stories. Or something urgent appeared in a production system. Standup can be a place to discuss the plans and to work on the most important things.

How to have a good standup

Standup is not a mandatory meeting.

Period. The purpose of your team is to bring value to your customers. The team is doing that by writing code, reviewing it, testing and deploying to production.  Meetings are tools to help doing those activities better. If somebody is deep inside the context, the standup will interrupt them. That's why the standup is not mandatory. And it's also why standups are better conducted in the morning or end of the day: you haven't dived yet into a task or took a pause. But if you're inside your work, feel free to skip.

Standup is not about what you were doing yesterday or discussing problems themselves; it's about if there anything blocking you from pushing the task further.

Don't focus on the persons. Iterate over stories/tasks: this is in progress, no blockers; that one is in the review, please take a look; these ones can not be tested due to an issue in the database in qa environment: we need to take action. Don't discuss the issue on the go: agree to discuss the issue after the call and pick the participants.

Standups are not required to be calls.

Some teams are distributed across many different timezones. When you are about to finish your day, your colleague on the West Cost just got to the office or home desk. Feel free to have asynchronous standup and post your updates in slack or other chat software.

That's it for now. Liked the article? Feel free to share and don't forget to subscribe :)