Jimmy McGill
This is the second post in a two-part series. Read the first post here.
When you use an Engineering Intelligence Solution to answer the classic three standup questions, you free up your team’s valuable meeting time for an even more impactful set of conversations. You’ll be able to spend less time gathering information and more time leveraging your expertise as a leader — once you’re no longer using facetime to surface issues, you can actually start solving them.
To frame these conversations, I recommend a new set of questions to ask in standup meetings:
- How can I help remove distractions?
- How can the team help reduce risk?
- Are we working on the right things?
Here’s how to get the most out of each one.
Question 1 to ask in standup meetings: How can I help remove distractions?
To most effectively answer this question, you’ll need to come to standup prepared. Take a look through your Engineering Intelligence Solution and keep an eye out for patterns that might indicate your team’s attention is fragmented, such as engineers who are making commits on multiple different Issues, or team members who have stopped committing for a few days. Code Climate's Software Engineering Intelligence (SEI) solution offers visualizations of individual developers’ coding activity, which makes these patterns particularly easy to spot.
If you notice an engineer bouncing around, committing to multiple pieces of work in a short time period, it’s possible that engineer is trying to do too much at once. Have a conversion with that developer, and find out exactly what’s causing them to work in this way. It’s possible that they’re trying to make progress on multiple fronts at the same time, or that they’re being pulled in different directions by external forces, bouncing from project to project whenever a stakeholder asks a question or requests a status update. As their manager, you’re in a position to help the engineer develop the tools they need to devote the necessary level of focus to each unit of work. Exactly how you help depends on the situation — a more junior engineer may benefit from some coaching in project management skills, while a more senior engineer may need assistance contextualizing and prioritizing their work.
Of course, every engineer is juggling multiple things at once, and it’s not uncommon for someone to jump to a new project while they’re waiting for a Pull Request (PR) to be reviewed. Still, there’s a point at which task switching becomes excessive, and the visualizations in an SEI platform make that really clear, revealing potentially problematic switching in a haphazard assortment of commits, or delays getting back to paused units of work.
Sometimes, the delay itself is noteworthy. If an engineer is committing to something every day, then stops for a significant period of time before picking it back up again, it’s likely they’ve been pulled away to work on something else. Given how much time engineering teams spend grooming and prioritizing their backlog, this sort of deviation from the plan can be problematic, and yet, well-meaning developers often say yes to side tasks and additional projects without thinking about the cost. As a leader, if you notice this occurring, you can help your team members determine whether unplanned work is worthy of urgent attention, and remind them to assess any new tasks with you before taking them on.
Question 2 to ask in standup meetings: How can the team help reduce risk?
This question gets to one of the key goals of standup meetings: spotting and resolving problems before they derail sprints. Work that is at-risk is work that has started to go off track but hasn’t gone completely off the rails yet, which means you have the opportunity to stay a step ahead of a real problem. An SEI platform will alert you whenever a unit of work meets your criteria for “at-risk,” whether it’s a PR that has stalled without review or one that has too many contributing engineers, giving you the opportunity to quickly get the work back on track.
While some at-risk work can be indicative of larger issues — outdated processes or recurring bottlenecks in your development pipeline — at-risk work is often the result of a miscommunication regarding who should be doing what. For example, it’s common to see work get stuck in work in Code Review because everyone thought it was being reviewed by someone else on the team. When you bring risky units of work to standup for discussion, your team can quickly implement any straightforward fixes, then set aside time to work through bigger issues.
Question 3 to ask in standup meetings: Are we working on the right things?
With an SEI solution, you can easily see what units of work are progressing, so you can ensure your team members are working on the right things. Let’s say you prioritized tickets coming into your sprint, but notice that a developer is committing against the lowest priority Issue — you can discuss this as a team and rebuild alignment in the moment, rather than pretending you’ll always get it right at the top of the sprint. Almost certainly there was a miscommunication, and the developer jumped on what they thought was an important unit of work, though it’s also possible that an engineer thought the low-priority item was easiest to tackle and wanted to get it out of the way. This is rarely a good reason not to work on the highest priority things, and you can help coach the developer back to more important units of work. In some cases, the low-priority item may be the only thing the developer understood, so they jumped into it despite its low importance. This is important to know and address because if one person on the team doesn’t understand something, chances are other members of the team are also confused.
Whatever caused the low-priority item to be started, the team now has the opportunity to decide what to do about the unit of work in question. It may be that the work is so far along it makes sense to finish it, or it may be something the team decides to pause until higher-priority work is completed. Without a SEI solution, there would be no choice to make, as you’d only find out that someone was working on the ‘wrong’ thing after the work was already complete.
Data is a Powerful Tool for Skilled Managers
Though some leaders hesitate to leverage data, fearing that it breeds micromanagement, it’s important to remember that you’re already gathering information about stalled work or stuck engineers. Standups are one of the many ways managers seek out that information, but they’re not the most efficient way, since meeting time is better used for solving problems than surfacing them.
True micromanagement is not found in the gathering of data, but in how that data is used; micromanagers wield punishments and prescribe solutions, while great managers ask questions, offer guidance, and help their teams collaborate on solutions. With a Software Engineering Intelligence (SEI) solution pointing you towards work that needs attention, you’ll spend less time looking for opportunities to help and more time actually managing your team.
Every day, engineering leaders ask their team members the same three standup questions to ensure the software development engine hasn’t come to a complete stop. It’s excruciatingly boring to be asked the same questions day in and day out, and it’s not a productive use of engineers’ time. These questions — the “are things moving?” questions — can be answered with the help of a Software Engineering Intelligence (SEI) solution, like Code Climate, freeing up valuable standup time for an even more impactful set of questions, the “how can we move faster?” questions. These are the questions that dig deeper into a team’s processes and practices, helping leaders identify opportunities for improvement and drive excellence on their teams.
In this two-post series, I’ll explain how data can help you answer the classic standup questions, then walk through the “next three questions,” that every engineering leader should be asking to level up their standups — and level up their team.
First, the classic questions:
- What did you do yesterday?
- What will you do today?
- What (if anything) is blocking your progress?
Let’s dig in.
Standup questions one and two: What did you do yesterday? What will you do today?
These questions are meant to help you understand what progress your team has made so far, so you can assess your team’s output within the context of your current sprint or cycle. In comparing what’s been done so far to what’s planned, you can get a sense of the sprint’s status.
Rather than ask your developers for a rundown of yesterday’s completed tasks and today’s to-do list, let the data speak for itself. You could do this by running a Git diff for every branch, or you could let Code Climate's SEI platform do the work, drawing connections between Commits and Issues and providing an accurate view of what your team is working on. This can also help you check that the team is prioritizing appropriately, and working on the most impactful Issues. You can also review the Issues that have yet to be started to determine whether the team is saving the trickier work for last. This isn’t necessarily a problem, but it could indicate that a slowdown is to come, and may be worth discussing during standup.
Of course, data won’t tell you for sure whether your team will hit its deadline, but it will give you a big picture view of how your sprint is progressing and where the team might need your help.
Standup question three: What (if anything) is blocking your progress?
Once you have a high-level understanding of the progress of your current iteration, you’ll want to know if there’s anything that might throw it off track. Developers might be hesitant to call out blockers, preferring instead to solve problems themselves, or they may lack the context to foresee potential slowdowns. Data addresses both of those problems, though the relevant information has historically been harder to find, as it’s spread throughout your VCS and project management tools. This is where a Software Engineering Intelligence (SEI) solution is particularly valuable — Code Climate can even send you a customized alert when a particular unit of work is stuck or at risk.
Work that is stuck may have gone a few days without a Commit, or may be marked “In Progress” in Jira for an atypical length of time. Work that is at risk is work that is not moving through the software development pipeline as expected, and which may become a bottleneck if not addressed. Though the signs of risk vary from team to team, Pull Requests with high levels of Rework, or many comments or Review Cycles are worth further investigation, as are PRs that haven’t been picked up for review in a timely fashion.
Data can also help you identify possible blockers in developers’ collaboration patterns. Every engineer will have their own opinion of how the team is working, and though it’s important to understand how engineers are feeling about the current state of collaboration on the team, it’s critical to check any hidden biases with objective data.
Start by looking at the distribution of work across the team. Is there someone who is overloaded, or someone who isn’t getting work? Code Climate makes this easy with a Work in Progress metric that tells you how much each engineer is working on at a given time. Then, to get a sense of the team’s broad collaboration patterns, it can be helpful to determine how many engineers are working on the same Issue or Pull Request. This way, you can be aware of a possible “too many cooks” situation, or dependencies that may impact delivery.
So, what standup questions should you be asking instead?
When you enter standup with this information, you can skip past the classic three standup questions in favor of three more impactful questions:
- How can I help remove distractions?
- How can the team help resolve that risk?
- Are we working on the right things (see what people are working on, blend that with your context)?
The answers to these questions will help you move beyond a short-term focus on getting work done and help you get to the next level, where you’re focused on helping your team excel. Find out how in my next post.
This is the first post in a two-part series. Read the second post here.