Avoiding rolling conversations during standups

Standups are one of the most important ceremonies in an Agile team. It keeps members up to date with the overall status of an ongoing sprint and encourages individual accountability by requiring members to discuss what they’re working on and any impediments that might be affecting them.

By discussing these issues as a team, it also provides an opportunity for colleagues to raise questions, provide solutions and to offer advice. What it should not do, however, is create rolling conversations about ongoing issues or future tasks that ought to be discussed at a separate meeting.

As a general rule, a standup should not last more than ten to fifteen minutes, or two minutes per person. We have found this to be enough time to discuss what we did yesterday, what we’re doing today and any blockers we have encountered or might encounter.

Many people suggest forcing teams to remain standing (as should be expected) helps keep these ceremonies short, but we have found this depends entirely on the environment. If members are stood staring at a project white board while taking turns to discuss what they’re working on instead of facing other members of the team, it can actually encourage ongoing conversations which are not appropriate for a standup.

By contrast, having members face each other while standing seems to reduce the risk of a short conversation turning into a rolling discussion that should ideally be parked for a separate meeting. This is because standups are usually prolonged as a result of two people discussing specific issues with each other; if they are facing other members of the team, it becomes far more obvious to them that they’re making other colleagues remain standing just to listen to their surely interesting, but irrelevant, one-to-one conversation.

Another common problem with standups is members not participating correctly. As soon as you start witnessing colleagues just pointing out what they’re working on today without properly discussing what they did yesterday and what blockers they might encounter, you are no longer participating in a standup and are violating a principle rule of Agile.

Standups are designed to enforce shared accountability. The reason it is important to discuss what you actually did yesterday is because it might differ from what you said you would do yesterday; and if that’s the case, other members may choose to raise that discrepancy with you if a reasonable explanation wasn’t provided as to why. This in itself is a form of shared accountability; it is the expectation that other members will call you out if you don’t properly explain what you did yesterday, what you are doing today and any impediments you might encounter. This increases individual responsibility to get work done. There is a reason standups are designed this way.

If you allow people to fall back to past habits, you can end up finishing sprints with surprise burndown charts that need to be explained to the rest of your organisation.

Strive for simplicity over complexity.

In most aspects of life, people seem to assume the higher you get, the more complex your life has to become. Whether that’s starting a family, running a business or accepting a promotion with more responsibilities.

The problem with this thought process is that by not challenging against the need for more complexity, you are reducing your ability to have the necessary clarity and focus on the things that actually matter the most. There’s a big difference between something that is inherently complex (like string theory) and something unnecessarily complex (like laws and regulations).

Take running a company: a lot of responsibility comes with this role. You might be reporting into multiple investors, managing several teams and be under commitments with many people across your organisation. You’ll also be responsible for the strategic direction of the company.

When faced with these kind of challenges, people often become confused about their priorities; often caused by personal pressure, illogical thinking and from distractions by those around them. The most important lesson anyone can learn is to listen to yourself and to follow your instinct. Don’t allow the thought process of others take place of yours.

An interesting problem that faces software engineers in particular is the balance between getting a product to market (the economic demand) and the desire to maintain technical quality (the intellectual demand). Agile methodology teaches us a way to balance both priorities by encouraging discussion between the stakeholders to identify the minimum viable feature set possible within the provided timescales.

This process allows teams to dissect the real requirements of a project that might have many moving parts; and by having all stakeholders involved in that process, each side has the opportunity to see and understand the challenges facing other colleagues across the organisation. By simplifying the entire process, it encourages teams to break up requirements into manageable chunks and to discourage decision-makers from making decisions without being fully aware of the consequences.

The truth is, complexity is in the eyes of the beholder. By identifying ways to break down and simplify challenges, we are far more capable at solving them. This applies to software developers in the same way as it applies to senior managers. You should always challenge the need for complexity and forever strive for the elegance of simplicity.

When work gets tough, work smarter – not harder.