How to have an effective daily standup

The software development landscape has changed much in the past decade. Ten years ago, most organizations were struggling with developing software using Waterfall like development methodologies. Nowadays, most companies are trying to change to agile methods, with varying degrees of success.

Changing to an agile workflow is difficult when a company is organized around a waterfall workflow. Not only does it need significant support from management, but most importantly it requires a change of mind from the developers themselves.

When working in a waterfall guided project, all is easy. You write the spec, or have it written for you. Then you can start developing it and deliver the result once you’re done. Then follows the repair phase of the damage you’ve created (usually called the “test” phase). Basically, you’re only concerned by getting the product to work in a technical sense.

Transforming to working agile

In contrast, the agile ways of working force developers to think more about what the users of the product would need. Instead of working through a spec, the team members must ask themselves which problem they are solving, and for which stakeholder. A good developer will speak up when he encounters user stories that help no one, to maximize the amount of work not done.

Apart from that, the team members must also learn to split up the work into manageable increments, where each increments adds value to some stakeholder. In my experience, this is a skill that requires practice to master. Developers used to waterfall working lack this skill.

The consequences of these aspects is that many companies struggle with the agile transformation. They either follow agile to the letter, or invent their own agile process where the real agile aspects are inadvertently left out.

There may also be other aspects involved that impede changing to agile. For example, in the embedded industry that I am working in, the actual product is not just software, it is a machine or a mechatronic component. However, hardware design is almost impossible to do incrementally since the build cost is huge; apart from the purchasing cost, it also takes weeks or months to get from design to a built product.

Agile is about feedback

One of the core principles of agile is that of feedback at all levels. That is the primary reason why stories are user oriented and small: so that the user can provide its valuable feedback as early as possible. That is the primary reason for getting “Working software in the hands of the user”: to have feedback on all development steps, from initial idea to deployment. That is the primary reason for Scrum working with sprints, and Kanban limiting work in progress: to have a continuous flow of feedback, to improve both the product and the process continuously.

Issues with the daily standup

Reasoned from the above principles, the daily standup is an important mechanism to obtain feedback and manage the sprint. It is one of the smallest feedback cycles. However, in my experience, it is almost never exploited in a way to obtain the most value. Which is a bit sad, since it is one of the most expensive meetings. It is expensive for two reasons: it occurs daily, so even if the team manages to limit it to the prescribed 15 minutes, then a two-week sprint still consumes 10 * 15 = 2,5 hours of daily standup time per team member. The other reason is that it interrupts the whole team, making the total time wasted much larger than the time spent in the meeting itself.

What is often going wrong during the standup, you ask me? I’ve experienced a number of things:

Standup with people that are not a team

I’ve seen this happening in different forms. At one situation, the whole software department (~12 developers) were performing a standup even though most of them were working on entirely different things. Most of what was said was not useful to the other participants. This was a complete waste of time.

In another occasion, people were put into “teams” but still had to work on different things. Although formally they form a team, in practice they don’t, so they are also not interested in each others progress. This had at least the advantage that the team members that actually did work together did have a specific update moment.

Elaborating on uninteresting technical details

I’ve also seen this happen too often: one team member is stuck on some technical problem and indicates this. Often he’s happy to ask for help, so he starts by explaining the problem in detail. The other developers, friendly as they are, want to reach a hand and start offering all kinds of suggestions. Within seconds, the standup meeting has transformed into a discussion about a technical detail, in which only two or three team members are engaged and the others are standing aside with a glassy stare. This has two large drawbacks: for the glassy-staring developers, the standup is becoming a mayor annoyance, and also the standup easily exceeds its 15 minute time window, making it even more expensive than it already is.

Asking the three standup questions

Maybe I’m going insane here. But I honestly think those three standup questions (you know them: what did you do yesterday? What will you be doing today? Are there any impediments?) are not the best way to perform a standup. They’re an invitation to the individualism, which is against the basic premise that the team is the smallest entity in agile. So if you’re working together as a team, then it is already sufficiently clear what the other members did and what they’re stuck on. And what they will be doing today should be decided as a team. Even more so when you’re using a digital Scrum or Kanban board where the names are assigned to the stories.

But the main problem that I have with these questions is that they miss the point. Sure, they may contribute to sharing knowledge within the team, but they don’t encourage to think about a commitment for the coming day very much. Look at it this way: if all team members have dutifully answered those questions, would it then be clear for everyone that the team is on track to completing the sprint? After all, the goal of the daily standup is to make a plan for the next 24 hours, not to have a status meeting.

Standup improvements

When you find yourself in a particular situation, it can be difficult to see possibilities for improvement. However, it is clear that improving the standup meeting will improve the team as a whole. There are several things you can do to improve the standup meeting of your team.

Improve on meeting format

Instead of putting each member in the spotlight in turn, the standup should be about progress. It should therefore be centered around the stories on the board, not the people. For example, you can ask for each story in progress: “What is needed to finish this story today?”.

If you have to stick to the traditional format, then please tell what’s worth listening to. No need to say things that your colleagues don’t interest.

Only people that work as a team

there is really no need for people that don’t work together to have standup together. If you find yourself in such a situation, ask what would be lost if you skip the daily standup. It is in the best interest of everyone.

Have technical discussions outside the standup meeting

during the standup, you can indicate you need help and find someone to help you. But possible solutions should be find outside the meeting. A very effective technique to help in this regard is applying ELMO.

Asynchronous standups

I can’t say much about it because I have no experience. But I thought it would be worthwhile to mention it here. It may be an idea to reduce the time impact that the standup has, especially in case of partially remote working teams.