7 ways to make daily check-ins more effective for developers

Check-ins are quick, daily meetings where team members get together and discuss what they did yesterday, what they plan to do today, and any roadblocks or issues they may have encountered.

In short, it’s about staying in sync.

But too often, companies treat check-ins as a formality: after developers list items on their to-do lists, the team disperses, and everyone goes back to work.

Luckily, there are ways to make check-ins more engaging, and in this article, we’ll discuss seven of them. 

Stay tuned!

While developers are well-versed at finding answers to their coding problems online or among colleagues, check-ins can also serve as an excellent chance for them to ask for help.

You can rest assured that another developer on the team has probably experienced the same issue and might know an easy fix. Why not then use this opportunity to ask for advice?

The following example from Reddit emphasizes the importance of asking for assistance during daily stand-ups.

Another example comes from Rish Chowdhry, a software developer who often uses check-ins to solicit help with issues he is encountering.

One time he was having a hard time with asynchronous calls from AWS Lambda. During the check-in, a coworker recommended a solution, and the problem was instantly resolved.

But if you suggest this approach to your developers, they might ask: “Aren’t daily check-ins meant for updates? 

If we all start bringing out issues and asking for assistance, won’t check-in turn into a long and exhausting meeting?”

And their questions would be spot-on.

However, while it is true that these meetings should be used to keep team members up-to-date about the goings-on in the team, there is nothing to say that you can’t open a discussion about any issues they may be facing.

In fact, this kind of discussion can actually make check-ins much more valuable for everyone involved, as another Reddit user suggests.

And to answer the second question, if you want to avoid turning your check-in into a full-length meeting, you can leave a few minutes at the end of the sessions to resolve issues. 

At least, that’s what software developer Milos Zivkovic recommends:

William Chin, a product manager at Telus, suggests a slightly different approach: developers should report any setbacks they’re dealing with and ask for help immediately but only address them at the end of the check-in.

After each check-in, he always sets aside 10 or 15 minutes in case the team wants to stay and help someone solve technical problems.

Whatever option you choose to follow, keep in mind that there’s nothing wrong with asking for help during the daily check-ins and you should encourage your team members to do so.

You might be surprised how many developers are ready to pitch in and offer assistance, either during the meeting or shortly after. 

Although daily check-ins aren’t meant to be a social event, it’s still important that developers are able to have some sort of social interaction.

In order to add a bit of fun to the equation, you can kick off your check-ins with a quick icebreaker or another engaging activity.

For example, Braden Kowitz, a design manager at Stripe, suggests you do a quick check-in round before each meeting. By that, he means that everyone should take turns talking about how they’re doing before the meeting begins.

The advice Braden gives about meetings in general is applicable to check-ins as well.

Sharing personal stories with coworkers may seem to take away from productivity, but it can actually create stronger bonds between them.

As Dan Pupius, co-founder and CEO at Range, points out, check-in rounds help us understand each other better and see things from another person’s perspective.

He also gives a real-world example—we may think a coworker’s behavior is rude, but it could be just that they’re tired after spending the night with a sick child.

Bear in mind that stand-ups should last no more than 15 minutes, so it would be a good idea to keep your check-in rounds and other icebreaker activities short and sweet.

For instance, one Reddit user shared how he used to warm up his team on Fridays by asking them to share their weekend plans along with updates on their tasks.

The team at Zurb, the creators of the Helio app, went a step further and created a fun tradition to keep their check-ins interesting and engaging.

Every morning, they gather around the kitchen table to hold their daily meeting. The team passes around an Angry Bird plush toy as someone talks. 

Each person takes a turn holding the toy and talking about what they’re working on.

This creates a sense of camaraderie, and it helps the team stay engaged.

All in all, adding a little bit of fun to your check-ins can help you keep your team focused and motivated.

You don’t need to use props as Zurb does or create some kind of elaborate skits—just adding a little bit of levity here and there and showing genuine interest in how the team is doing personally will be just as effective.

Check-ins offer more than an opportunity to interact with other developers or share updates—they can also provide valuable business context.

Decision-making is a large part of the work for developers, whether they are making small decisions about coding or designing the architecture of the software.

Understanding how to make those decisions is often dependent on insight into the company’s direction. And daily check-ins can be a great way to gain that insight.

However, Mark Porter, CTO at MongoDB, notes that this isn’t always the case as development teams are often “misunderstood, mismanaged, and marginalized inside both large and small companies.”

Therefore, he gives a few tips on how to improve the situation.

Bringing context to the developers’ work during daily check-ins will provide them the opportunity to connect the dots and create a shared understanding of how an app or software works and why certain decisions were made.

For example, bringing in a CTO or a member from another department to share updates from the business side can make all the difference in how well the team performs.

Jessica France, a product manager at Roots Automation, states that the presence of the company’s CTO at daily check-ins helps their developers tremendously.

This may seem surprising at first, as CTOs often have little to do with the actual coding.

However, the CTO’s presence allows Root’s developers to understand how their work fits into the company’s overall strategy, and that has proven indispensable for their performance.

Michael Sung, a director of Engineering at Hopper, is on the same page when he states that the business context was of utter importance for the success of the check-ins at Rippling. 

He states the following:

Sung, who held the position of senior engineering manager at Rippling when he made this statement, was speaking from personal experience.

According to him, at Rippling’s, developers have a daily check-in that focuses on customer needs and includes various departments of the company—development, support, sales, and implementation teams.

Although development and support team members are consistently present, other teams can step in or out as needed.

By keeping the focus on how the changes affect customers, they enable developers to learn about how their code will be used, and thus how it fits into the bigger picture.

Developers often operate in silos, focusing on their own tasks without fully understanding how their work contributes to the larger goals of the company. 

And as you can see from Rippling’s example, a good check-in has the potential to turn this around.

Reducing the number of participants at daily check-ins may help improve their efficiency.

Here’s why. The more employees attend a meeting, the less time each person gets to speak.

As a result, this type of meeting can become disjointed and unfocused.

The Scrum Guide recommends that check-in meetings have no more than nine people in attendance.

But as the Quora user correctly noted in the picture below, although they should be kept to a reasonable number of participants, this is not always an indicator that they’ll be successful.

Nevertheless, a good rule of thumb here is to keep your attendance list small, so the team won’t lose focus or momentum.

Harper Maddox, a senior engineering manager at Indeed, learned this lesson firsthand. 

At Shipwell, where he worked as the director of Software engineering, his team grew larger.

Because of the extra people involved in each check-in, they started to last between 30 minutes and an hour.

This became an issue, so another team member came up with a solution—introducing the squad model.

The squad model rose to fame after Spotify made it a core part of their team structure. 

It’s basically a way of organizing teams that breaks down the large team into smaller, cross-functional units called squads, as shown in the picture below.

Squads are small enough to tackle a check-in in just 10 minutes but still large enough to compose a fully-functioning team.

By implementing the squad model, they were able to keep their check-ins short and focused and, as a result, increased their productivity.

No matter what model you choose, keep in mind that the smaller your list of participants is, the more effectively you will be able to hold a daily check-in.

Therefore, when you’re trying to decide whether or not someone needs to be present, ask yourself if the person’s presence is absolutely necessary.

If it isn’t, then keep it simple and leave them out.

If you hold daily check-in meetings but fail to ask your team for feedback, you could be overlooking some great ideas and problem-solving suggestions.

Taking a few minutes to discuss with team members what they think of the assigned tasks can be a game changer when it comes to the effectiveness of this type of meeting.

For example, when Brian Wones was working as the head of product at Wurk, a company that provides an HR platform to cannabis companies, getting feedback during daily check-ins was essential.

As a rapidly growing startup in the dynamic cannabis industry, the feedback allowed them to identify real-time challenges that would have otherwise possibly gone unnoticed.

However, due to the time limits in check-ins, it may be challenging to make time for feedback.

In that case, if you find that you are approaching your 15-minute time frame, it would be wise to hold your feedback session outside of check-in.

You can also use tools such as Rate The Meeting (shown in the picture below), Hypercontext, Fellow, or even Google Forms to collect feedback afterward if you don’t want to lose any valuable insight.

It’s also important to note that you should collect feedback not only about the work itself but also about how the check-ins are run. 

For example, Henry Dittmer, while working as a director of Engineering at Location3, saw big changes coming out of collecting feedback about the check-ins themselves.

Let’s see what he has to say on the topic:

As you can see, feedback from peers can have a big impact on not only how developers work but also how they structure their meetings. 

For all these reasons, setting aside some time for reflection is a must.

There has been a lot of debate about whether product managers or product owners, as they’re called in the scrum, should attend daily check-ins or not.

For example, one Reddit user has strong opinions on why managers shouldn’t attend these kinds of meetings.

According to Andres O’Brien, a principal engineer at ServiceCore, keeping managers at bay was the core reason the check-ins at his company became more effective.

On the other hand, Jessica Crowley, a lead enterprise agile consultant, is on the opposite side of the argument when she states:

One potential problem with managers attending check-ins is that they may not have enough technical knowledge to understand developers’ day-to-day tasks.

This means that they won’t be able to lend their expertise to help them to overcome their issues.

This also means that they may have additional questions, which could prolong the meeting.

At the same time, a daily check-in can give them valuable insight into how the team is completing their work.

If the team continues to encounter obstacles, the manager may call for a change in direction.

On the other hand, if it’s going well, they can rush the project or line up more work.

Since both sides of the argument make some compelling points, perhaps the best way to include stakeholders in non-developer roles is to strike a balance between both approaches.

As they can give valuable contributions, they should, by all means, attend daily check-ins from time to time, especially on important days when there are new features being discussed or a high-priority bug is being worked on.

But perhaps it is best if they attend only those meetings in which their presence is truly necessary. 

That way, the team can focus on the matters at hand without being distracted by their superior’s presence.

A good stand-up meeting should be a recurring event. Thus it’s helpful to have a go-to template or agenda that you can fall back on.

First, however, we should note that it’s in the very definition of check-in meetings to already come up with a predefined agenda and cover three questions.

Although we’ve already mentioned these questions in this article, let’s repeat them here for clarity, with an example of what such an agenda would look like.

For more accurate check-ins, you can also add your own topics to the list.

For example, Matthew Jones, a lead software developer and the owner of the blog Exception Not Found, recommends an agenda that has two more topics.

By adding items that are pending or need attention to the agenda, Jones ensures that no issues are falling through the cracks during check-ins and that everyone stays on schedule.

This format, called the Round Robin, is by far the most common in check-in meetings.

However, some teams have had mixed results with it.

They notice that when team members speak one at a time, in a predetermined order, they tend not to pay attention to what the others are saying because they’re busy preparing their own responses.

That’s why they prefer the Walk the board format instead, which you can see below.

In this scenario, team members walk through all their tasks on a task board (i.e., a Kanban board) from left to right, discussing those that are closest to being done first.

The idea is that the team members walk the board together and discuss each task, one at a time.

Since the discussion is linear, everyone can pay attention to what others are saying.

Here’s an example of what the agenda for this approach might look like.

Of course, you can choose whichever agenda is best for you and your team.

However, whichever agenda you choose, you should be consistent in following it, in order to ensure that the discussions flow in an orderly fashion.

Plus, it would be wise to send it to all developers ahead of time, so that they can come to the check-in prepared.

The check-in meeting is a staple of software development, and for a good reason—it’s vital for keeping everyone aligned because it ensures that no one falls behind or forgets about the ongoing task.

To make sure such meetings are productive, in this article, we’ve shown you how to make your check-in meetings more effective by using seven strategies.

You don’t need to use all of these strategies at once, but they’ll all help you make your check-ins more efficient and productive.