Daily check-ins — also known as stand-ups or huddles — are such a fundamental part of agile that it’s hard to imagine the software development process without them. But at many companies, check-ins are more of an institution than a useful practice: people list a few items on their to-do lists, the team breaks huddle, and everyone goes back to doing what they were doing.
William Chin, a product manager at Telus and a freelance consultant, said daily check-ins are supposed to cover three big questions: what you accomplished yesterday, what you’re working on today and whether you’ve run into any blockers. But running effective check-ins takes more thought than just going through the questions.
“I’m not a big proponent of doing the three questions, I just feel like it’s too constricting,” Chin said. “I want my team to be a loving organization — agile is always about interaction and people over processes and tools. So value the people more than the process.”
Tips for Running Effective Daily Check-Ins
- Crowd-source programming challenges. It’s an opportunity for developers to ask their colleagues for help on blockers.
- Leave technical discussions for the end. Allocate time at the end of check-ins for in-depth discussions to prevent meetings from running long.
- Make it fun. The time can be used for team building and celebrating small wins.
- Provide business context. Giving developers updates on the business side helps them make better programming decisions.
- Keep group sizes small. If your check-ins have more than six people, consider breaking them up into smaller groups.
To prevent daily check-ins from becoming rote and participants from tuning out, check-ins should offer something useful back to the people in the room.
“If you see that people are tuning out, the reason they’re tuning out is because the daily isn’t relevant to them,” said Courtney Hemphill, a technical lead at software development consultancy Carbon Five.
Luckily, there are ways to make check-ins useful to its participants — that can mean introducing fun activities or business updates into check-ins to make them more engaging and relevant to participants’ work, or practical solutions like reducing the number of participants to make check-ins more relevant for everyone involved.
Product Managers Should Attend to Monitor Progress
The most common reason for doing daily check-ins is to help product managers stay on top of a project’s progress, so it’s generally a good idea for product managers to attend.
Chin said product owners are the “bridge” between stakeholders, clients and the development team.
Before he adopted daily check-ins, Chin felt that “managers and stakeholders, when you requested something, you had no idea what was happening behind the scenes,” he said. “It was just this thing that you would ask and pay for, and then three months later, you may have something that’s delivered that you want, but it probably isn’t the specifications or scope that you actually wanted.”
With daily check-ins, product managers can get a detailed understanding of how the project is progressing. If it keeps running into roadblocks, the product manager can ask for a course adjustment, and if the project is going faster than expected, they can prepare for an early release or line up additional work so developers aren’t sitting idle.
Check-ins are great for ensuring a constant flow of communication between developers and the business side, but it’s not enough that product managers get something out of the process. Developers need to feel engaged as well, as otherwise they won’t prioritize check-ins and they may give vague updates — and that’s not useful for the product manager’s understanding of the project either.
Encourage Developers to Get Help from Peers
An easy way to make check-ins useful for developers is to use the time to crowd-source solutions to technical challenges.
Although developers all know to turn to sites like Stack Overflow when encountering problems, searching for solutions online can take quite a bit of skill. You first have to know enough about what’s causing the problem in order to properly search for a solution.
But, chances are, another developer on your team or at the company has run into the exact same problem you’re encountering. Check-ins can be a way to encourage developers to take advantage of their colleagues’ experience and obtain a fix faster than when left on their own.
Software developer Rish Chowdhry often gets answers to his programming questions during check-ins. The morning before we spoke, Chowdhry was having a problem making asynchronous calls from AWS Lambda. But during the team’s virtual check-in, another person told him about a simple fix, and the problem was resolved immediately.
“If you see that people are tuning out, the reason they’re tuning out is because the daily isn’t relevant to them.”
“He said, ‘Change this one thing,’ and I do it, and then I’m totally unblocked,” Chowdhry said.
Sometimes it’s easy to get sidetracked by a single problem and have the meeting run much longer than intended. If it happens too often, that can also lead to problems around engagement.
Chin’s solution is to encourage developers to bring up blockers during check-ins, but to save crowd-sourcing until the end. He always allocates 10 or 15 minutes following check-ins in case the team wants to stick around and help someone solve technical problems.
It’s a balance between keeping daily check-ins short and not pushing solutioning too far down the road. Check-ins shouldn’t get bogged down by too many technical discussions, but there’s also the risk developers won’t get anything useful from them. The trick is to not let too much of the day come between the check-in and the solutioning.
Chin said it’s best to do it right after the check-in, “instead of booking a follow-up meeting later in the day when the developers are busy doing the work,” he said. “It’s fresh in everyone’s minds.”
Make Time for Team Building
Apart from helping developers crowd-source programming challenges, check-ins also give teams an opportunity to see one another and socialize.
Although that’s not their intended purpose in agile, Chin has found the social aspect of daily check-ins important — especially while teams are working remotely. He usually kicks off check-ins with an ice breaker, such as short video clips of funny things he saw over the weekend.
“I think it’s all about humanization,” Chin said. “That sort of fun camaraderie really helps to solidify your team and give it that esprit de corps. It makes it a more fun environment, especially now.”
“That sort of fun camaraderie really helps to solidify your team and give it that esprit de corps.”
It’s also an opportunity to catch struggling team members early on. After seeing a developer struggle through a few check-ins, Chin was able to take him aside and offer support.
But check-ins can also be used to celebrate wins, big or small.
“Maybe a developer really chewed through three or four tickets within half a sprint,” Chin said. “Why not just say, ‘You’re doing a great job.’ Little wins help cement that team dynamic and give people the praise that they need, especially if it’s been a tough time.”
Keep Developers In the Loop About the Business Side
Interacting with other developers isn’t the only way participants can get something valuable from check-ins. At the small startup product manager Jessica France’s works for, Roots Automation, developers find having the company CTO present to be the most helpful part.
Considering how far removed CTOs can be from the programming work developers do, that may be surprising. But developers at Roots enjoy hearing about the direction of the company and learning how the work they do ties in with the overall vision.
Developers make a lot of decisions throughout their work, whether they are small technical decisions or architectural design decisions. Knowing how to make those decisions often depends on insight into the direction of the company and whether the technical result is aligned with its business goals.
“When you give developers more context of what their impact is — for customers, for the product and for the business — they just make better decisions.”
“When you give developers more context of what their impact is — for customers, for the product and for the business — they just make better decisions,” Hemphill said. “They make better decisions around how to do the right thing, how to slim down the work that they’re doing to focus more on the business objectives.”
For instance, if developers are trying to decide how to structure a database, it helps to know whether the project scope is going to be expanded to include more data types later on. Or if developers are considering breaking up functionality in the codebase into different sections, that can depend on how important the functionality will be in the future.
Teams don’t have to bring in the CTO to give this type of insight. It can be helpful just to have someone from the product side at the check-ins to share updates from the business side. That person could share wins as well, such as if the developers’ work has driven more customers to the product or improved a key performance indicator. But most importantly, they can communicate top-down objectives to the developers and give valuable context.
Don’t Let Meeting Sizes Grow Too Big
Another thing to consider is the best time to hold check-ins, and whom to include. Most teams opt to do them at the beginning of the day, so developers can share their plans for the day before they have settled into their tasks.
But that’s not always possible, because many development teams have remote members who live in vastly different time zones. In those circumstances, teams might have the meetings during the middle of the day when everyone is online, or opt to have multiple meetings.
“This is always the hardest part, the most annoying,” Hemphill said. “Carbon Five has four offices across the two coasts, so we often have to manage time zones. And additionally, during the pandemic, people are just strewn everywhere.”
Hemphill’s teams deal with time zones by leaving Slack messages at the end of the day for developers who will start work in a couple hours. This way, developers who are just starting their days don’t have to wait another few hours to know what others have done, and what work needs to be picked up.
The number of people at check-ins can also determine their effectiveness. At one point, France was on a team with 12 people at check-ins, but that proved to be too many. Now she joins a couple of separate check-ins, one for a small group of three developers, and one with six people.
“I find anywhere around those numbers to be quite an effective group at the moment,” France said. “Any more than six could be tricky, just from the broader team’s experience with 12 or so participants. If people did have a challenge or something, then you maybe don’t have enough time to address it and explain things properly before you really have to move on to the next person.”
