Daily standups
Chances are you already run daily standups, and your engineering team is used to them. Your standups might involve product owners or a scrum master in addition to the team. Perhaps everyone’s physically standing up in the corner of the office or calling in remotely. The logistics of your standups are probably under control. You’ve been using standups for their primary purpose according to their scrum methodology, which is to keep your team informed, connected, and calibrated throughout a sprint.
Standups are great check-ins to identify the status of a sprint, see what’s in progress and see what work is in review. They’re also helpful in identifying potential risks and blockers so you can remove roadblocks and keep your team on track.
In a standup, you might ask questions like:
- What did you work on yesterday?
- What are you working on today?
- What issues are blocking you?’
Those questions are meant to help flag blockers and create a sense of collaboration and shared contributions, but there may be times when you’re not convinced that standups are that useful or necessary for the team. Maybe work is progressing as usual, and no one seems to be running into any blockers. 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.
Self-reporting
Standups can be a compelling space for connecting the team and creating a rhythm, but it’s not uncommon for these meetings to experience some attrition at times. There are a few overarching themes teams may experience. One of those common themes includes issues with self-reporting. When you’re in the weeds with work, it can be challenging 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 knee-deep working on a particularly challenging problem and not realize that only when they find themselves churning on this problem for days that they’re stuck on. Maybe they just need someone to talk through the problem with, or perhaps 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.
Absentee management and micromanagement
Similarly, another limitation with standups is knowing when to offer 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. Additionally, some managers might over-correct and check-in far too often on a team member’s progress. There 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’s stuck or taking a project beyond what the business was asking for.
Git Analytics tools, such as Waydev and Gitprime, provide engineering managers with a birds-eye view over their engineering teams activity.
With data, 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 standup about something you see in the team’s data. Data drives healthier, more productive conversations. Without being connected to what’s going on, it can be more challenging to have timely and meaningful conversations.
Identifying issues and opportunities
With this said, what standups do really well is this: they help drive momentum and create alignment within the team, and they provide a space for team members to connect with others who are working on similar projects or have faced similar challenges before. The things that are harder to surface in a stand up are bottlenecks to work. Even more challenging to identify, are the underlying systematic issues that may be at hand. Wouldn’t your standups be more productive if you could dig into the actual roadblocks and bottlenecks in a sprint or that the team has frequently been experiencing scope creep late in their sprints? Are there opportunities to cross-train team members on new areas of the code?
This chapter will show you how to use analytics about the development process so you can run more productive standups that lead an overall healthier way of working to help the team execute business outcomes more predictable. You’ll see how you can have more targeted conversations about how things are going. You’ll see how you can experiment with the timing or flow of your standups. You could begin with data instead of starting every standup by saying, ‘so who wants to go first?’
Data-driven standups
You can start standups by going over what you see in the reports and then encourage more in-depth conversations about why different dynamics might be showing up in the data, what was challenging, what went smoothly, and what everyone would like to see moving forward. You’ll see how data regarding the development process can help you spot roadblocks and surface discussions about trends and patterns like process issues and collaborative solutions to those issues. You’ll see specific reports and use cases for each, so you can eliminate guesswork, not only about running productive standups, but also about how to actually use analytics about the development process to benefit the team as a whole. Data-driven standups can help your team feel more informed, connected, and calibrated, and can ultimately contribute to improved motivation and retention within the team.
The Work Log is a great way to find your bearings. The Work Log report helps you visualize work patterns and get a better understanding of how the team works. This report helps eliminate guesswork and knowing how things are going. It gives a voice to engineers who are quieter or working on less flashy work. It helps managers get visibility into their onboarding process, understand where their team is focusing their attention or notice when there’s an unexpected spike in activity.
Spotting work patterns
The Work Log also helps managers get a better understanding of their team’s work patterns, which will differ from one individual to the next. It’ll become easier to notice coaching opportunities to help team members practice healthier and more sustainable work behaviors, which in turn will benefit the team as a whole.
For example, when a team member has the habit of saving up their work for over a week or more and then submitting it for review all at once right before the deadline – that can create a lot of stress within the team as they will need to review a large amount of work with little time left in a sprint. That also limits the feedback the team can provide and increases the probability of introducing bugs to the codebase. If a manager sees this pattern, they can coach the team member to break up their work and make small, frequent commits, which will help their team review it earlier and provide for a more sustainable workflow for the team as a whole.
To understand the team’s work patterns, identify bottlenecks, and spot timely and meaningful areas for coaching, you first need to have visibility into the team’s progress. With the Work Log, you’ll see a visualization of work patterns in detail. The Work Log report brings in data from code commits where you’ll see a broader view of commit output. You can also see merge commits, PR open, PR merged, PR close and PR comments.
Depending on your use case, you can also view the work activity by team or by repo. With this report, we can see the team’s work patterns throughout a week or sprint. When we start getting comfortable with visualizing how various team members work, we can then begin to notice when something might be off or experimenting with processes or meeting times and having a data-driven discussion with the team around how that affects their workflow.
Improving your workflow
So if for example, you notice that there’s a drop in activity on Thursdays, the same day you have a specific weekly meeting, it might be worth talking to the team about whether it would be helpful to move that meeting to a different time or day, or even change how it’s structured. All we need to do in that situation is to bring this report to the standup and use it as a starting point for discussion. Then if the team thinks it would be beneficial to change the date or structure of that meeting, you can create a hypothesis together around whether those changes will help the team and not slow them down. Then bring that report back into your standup in a week or two weeks and assess how that change has affected the team. Managers can also use this report to see how work is being carried throughout the team and whether there’s anyone that’s maybe taking on too much and could delegate some of that work.
For example, if you see that one of your engineers (let’s call her Tracy) has been working on some weekends it might be a one-off situation. But if we look at previous weeks, you’ll see that Tracy continues to work on Saturdays and Sundays, and we should take that as a signal that she might be stretched too thin. You can look at what she’s working on in your project tracking system or by clicking on these specific commits and seeing the actual code. From there, you can start to look for opportunities to cross-train other team members on those work areas or otherwise, coach Tracy to delegate some of that work. This may also be a signal that you could set more realistic expectations with other teams or departments on what an individual contributor can and should produce.