Get the team in a rhythm


How many times a week do we have to go to an unplanned meeting? How often does this disrupt our work? How many meetings are actually useful? How often do these meetings take more than an hour? The answers vary, but typically it is more than 4, they disrupt work every time, next to none are useful, almost always they take more than an hour in discussion. You can become very good at having efficient meetings, but having less meetings is the more effective approach.


When a team is struggling to find focus, in many cases improving the rhythm is all that is needed in terms of management.


Useful meetings are those that come at a good time and are about the next thing you should be doing. A standup meeting early in the day can cut down on the time you spend groping around for the best thing to do next. A planning meeting is useful to figure out what the team is going to be doing in the sprint that is about to start. Cut down on all unplanned activities and hold all meetings at fixed times and locations.

Apart from forcing a rhythm with meeting schedules, it is very important for the physical and mental health of developers to take regular breaks. It can help a lot to informally synchronize these breaks by taking colleagues to the coffee machine or lunch room.

Even if rhythm is very important, pragmatism should not become secondary. Ad hoc design meetings, quick war room meetings, toilet breaks they are all ok to have; being too dogmatic about these things is dangerous.


When the team works in a shared rhythm it becomes easier to collaborate and you will see more flow going on. One of the golden rules that follows is that we never move a deadline. Failure is natural, the rejection of a hypothesis is fine. Moving a deadline often means the prolongation of a failed attempt.


A team we coached at one of our clients got in trouble. They had underestimated some work and decided to push all user stories at the same time in an all or nothing attempt and failed to deliver anything demoable at the end of the sprint. Then management agreed to not have the retrospective and planning meeting and just carry on for one more week. At the end of that week it turned out that most of the functionality was not according to the expectations. Not only did the team fail the previous sprint, but they also failed to properly plan this one. As a result two sprints were lost instead of one. The worst effect however was that the team got out of their rhythm and continued to have lower productivity and decreased motivation in the subsequent sprints.

The Xebia Essentials Cards

This page is part of the Xebia Essentials, a pack of flash cards about Software Development Done Right. You can get your own deck of Essentials cards in the Xebia store.