Effective Standups

Recently on one of my engagements, I came across a stand-up that, to put it bluntly, was a pointless waste of time.

The reasons why it was pointless was

• Poor quality of updates that revealed no new information we couldn’t find from the issue-tracker software we were using.
• Too many people involved and too many “business-as-usual” updates.
• Terribly long standups that went on for about 30 Minutes, everyday.
• Updates were not always relevant to all the members of the team
• Never really addressed a pressing question: Where do we stand with regard to the sprint?

Making your standups more effective

Every team is different — and so might be your stand-ups. However there are a few ground-rules to keep in mind, if you would want your stand-ups to be effective.

1. No Status Updates — Focus on “what my team needs to know”

The format of “What did I do yesterday”, “What do I plan to do today”, “What are my blockers” is fairly common in most stand-ups.

Many people mistake the “What I did yesterday” part of the stand-up update to be a status update to your manager / tech-lead / PO. A good example of such an update that I’ve seen in the past and immediately showed me this problem was “yesterday I had worked on the backend, today I will work on the frontend”.

Is that information that the team would absolutely need to know?

Well functioning teams trust their colleagues to do their jobs — and wouldn’t need them to provide status updates, or need other ways to micromanage them.

I would much rather rephrase the “What did I do yesterday?” question to “How closer are we to our sprint goal” and “What are my blockers to stop me from contributing to our sprint goal as per plan?”

This is important — because now your updates are centered around the result and not the effort. In most cases, your stakeholders will not care about the effort you put in, but the result you have.

You might was well start thinking along those terms.

Focusing on the result (which is the sprint goal), rather than the effort , I believe will better the quality of content by removing those status updates from stand-ups.

2. Is the “Walk The Wall” really a good stand-up methodology?

Over the recent past, I’ve come to dislike this stand-up format, in which the entire team would have the stand-up around the wall, a person who “drives” the stand-up would go card-by-card asking the developers working on the story for an update.

The reason why I dislike this format the most is because this format encourages developers to give status-updates. In short, that is what the format is — somebody goes card-by-card and asks the developers for a status of the card.

I’ve also seen that this format makes developers concerned only about the story / bug they are currently working on, an thereby they would have a myopic view of the work the entire team is doing— give their update and then switch off until the rest of the stand-up is done. This is frequently because most updates are business as usual, and often don’t matter. And hence good information is lost among a lot of noise.

3. Do not have a stand-up that takes more than 10 minutes

There’s a reason why the meeting is called a “stand-up” meeting — it’s because it supposed to be a short one.

Whatever the excuses are there for a long standup — including “we have a large team” needs to be addressed separately and should not be a reason for keeping standups more than 10 minutes long.

I would go as far as to say that the long stand-ups are a symptom of a bigger problem, should that be a large team, or even the that the team lacks a better communication channel than the morning stand-up. These are actual problems that need to be taken care of, separately.

4. If you don’t have something that the team needs to know, don’t say anything
This helps keep the noise to a minimum — to ensure that every update is an important one, and that every update requires the complete attention of every member of the team.

5. Have a “Purpose” for your stand-up meeting
If your team comes out of a stand-up meeting feeling that they learnt something that they might not have if not for the stand-up meeting, then you have a good stand-up. Else you might want to re-consider if you even need a stand-up.

The last point is just to drive home the point that we shouldn’t be doing a stand-up meeting because “all agile teams do standup meetings”. If your standup meetings reveal only the same information that something that your card-wall or a JIRA wall provides, then all that time you spend in the stand-up is wasted time that could have been spent for something more productive.

For every team, that “purpose” could be different — that’s something you will have to agree with your team.

In the end, we must understand that the every moment in the morning is when most of our productivity is at a maximum — and as such every minute of those hours must be spent wisely, and effectively.