Article

Start better stand-ups with data

There’s a good chance you’re already running daily standups. You’ve got your rhythm down, and your team knows what to expect. They may involve product owners or a scrum master, in addition to the team. Perhaps everyone is physically standing up somewhere in the office, or since Covid, calling in remotely. The logistics of your standups are probably under control. You've been using standups for their primary purpose, according to the scrum methodology, which is to keep your team informed, connected and calibrated throughout a sprint, but it's not uncommon for these meetings to experience some attrition at times. This waning of importance could be a result of stand-ups relying too heavily on anecdotal evidence, and lacking data to help drive a more impactful and collaborative conversation. 

So how do you know if you need to inject more metrics into your stand-ups? If there  aren't any processes or systems that the team thinks should be changed, and everything that's brought up in meetings seems to be really positive it may be a good time to peek under the hood a bit more. This doesn’t mean turning data into a weapon against the team, but rather the opposite. Software engineers are problem solvers at their core, and if they aren’t hashing out ways to fine-tune processes, and fix issues, it may be because nobody is fully aware of the issues. 

To give your stand-ups the data-driven shot in the arm they need, you first need to clearly identify the reason you’re holding the meetings in the first place. Here’s our take:

What’s the point of stand-ups anyway?

Stand-ups are great check-ins to identify the status of a sprint, see what's in progress and see what work is in review. It’s a great time to identify any risks, roadblocks and the like. They’re also a powerful space for connecting the team and creating a rhythm amongst the engineers.

Now that we’ve identified some key reasons for holding stand-ups, let’s break down how you can collaboratively bring more data into the meetings as a team. Typically there are a few overarching themes teams may experience.

The issue: Self-reporting isn’t always easy

When you're in the weeds of a project, it can be difficult to notice the broader patterns or recurring issues that a manager or team lead might be able to help you with. Sometimes an engineer might be grinding away on a particularly challenging problem and not realize that churning on this problem for days might mean they could benefit from some additional help. Maybe they just need someone to talk through the problem with, or maybe the problem is larger than that. The issue with self-reporting is often that team members face friction in moving their work forward all the time, and might not realize when it's worth bringing up in a team meeting. So team leads and managers might think everything is progressing as usual, without realizing that there's something they could help with.

The fix: Celebrate asking for help and prove success with data

Working with your team, you can identify the best metrics to measure when teammates may be getting stuck too long on difficult tasks. Using these agreed upon metrics in stand-ups can help teammates see if a particular developer is being held up by a task that others can help with. Because some developers may not be comfortable asking or may not always realize the need for help, there's an opportunity to acknowledge and praise those who are willing to self-report their issues, or as a team leader, set the example by asking for help yourself. 

Over time patterns will emerge in the data that will prove out self-reporting early creates a real difference in the team’s ability to overcome roadblocks and complete their work more accurately. The amazing byproduct of increasing self-reporting with the help of data is how it lowers stress levels of individual engineers while increasing collaboration across the team.

The issue: Trouble offering assistance

It can be tempting to walk around and ask people how things are going, and when they say it's fine you move along to the next person. On the other hand, some managers might check in far too often on a team member's progress, giving off the impression they’re being monitored. It can be a fine line between absentee management and micromanagement. You don't want to assume things are going fine, but you also don't want to interrupt when you think someone is stuck or taking a project beyond what the business was asking for. 

The fix: More data, fewer unknowns

Introducing the right data into stand-ups can shed light on the ebb and flow of your team’s development patterns. Rather than hounding them or quietly wondering how they’re doing, you can see work patterns and know when something seems off, or when work is progressing as usual. You can be confident when offering assistance or when bringing up a discussion in a stand-up about something you're seeing in the team's data. 

Data drives healthier, more productive conversations. Without being connected to what's going on, it can be more difficult to have timely and meaningful conversations. To make sure you’re offering assistance at the right times, you can use the following data:

Metrics for the stand-up meeting

Now that we’ve covered how using data in stand-up meetings can help engineering teams become more collaborative and unified while streamlining their development cycle, let’s break down some of the specific data you can introduce into your daily meetings:

  • Ticket log: There’s always a ticket or two that tends to bog your team down. Proactively review tickets as a team that have been stuck in a status or have a high amount of back-and-forth activity to spot issues. 

  • Work log: Understand what code was checked in, who checked it in and what type of commit it was, including individual code commits, merge commits and group commits, to see if there are any unexpected patterns.

  • Pull request activity: See how the team is working through tickets, how fast they’re closing them, how much discussion around the tickets there is and if there are roadblocks that can be alleviated.

  • Work type: Refer to what type of code the engineers are working on (new code, refactoring, churn, helping others) to see if anyone has an unusual workload trend.

  • Impact on codebase: Look at the importance and complexity of the code submissions. Because not all codes are created equal, it’s important to know how difficult a particular task is and how long it should take.

When used in stand-ups efficiently these metrics can help drive momentum and create alignment within the team. A well-run stand-up should provide space for team members to connect with others who are working on similar projects or have faced similar challenges before. Using data as a foundation to the daily meeting allows you to identify and dig into solving bottlenecks, and spot potential systemic issues with processes.

Get help with Pluralsight Flow

Not every team is equipped to extract the data needed to run more productive stand-ups in a way that is accessible to everyone. With Pluralsight Flow, you can lead your team to a more impactful daily stand-up, and ultimately a healthier way of working. Want to see how? Get started here.