Step Up Your Standups

This post is part of our historical archive. It represents the beliefs, actions, products, and services of Code Climate as of its publication date. Today, Code Climate focuses on providing enterprise leaders the software development data, context layer, and playbooks needed to build the AI-native software organization their enterprise needs. Head to codeclimate.com to learn more.

Dec 22, 2021 • 3 min read

Standups are a cornerstone of the Agile process and an essential ceremony in many engineering organizations. A great way to facilitate knowledge sharing, team cohesion, collaboration, and more, standups can help keep projects on track and clear of roadblocks. However, standups as we know them are in need of some TLC. When you meet with your team every day and ask the same questions, it can get monotonous, and engagement may be lackluster.

To step up your team’s standups, you’ll need to move beyond the typical standup questions. A Software Engineering Intelligence (SEI) platform like Code Climate can help you do that, making it possible to get your status updates before standup, so you can spend the meeting digging into at-risk work, addressing potential blockers, and helping to drive work forward. Code Climate aggregates data from DevOps and project management tools, acting as a single pane of glass for engineering managers to gain visibility into their team’s sprints and help them better prepare for the day ahead.

Without the help of an SEI platform, your standup likely looks something like this:

Engineering Manager to Dev: What will you do today?

Dev: Today I’m finishing up the Health Check feature. Dev2 had been working on it all week, but they passed it on to me before taking their vacation. Should have everything I need.

Engineering Manager: Great, let me know if there’s anything you’re missing.

Short and perfunctory, this conversation only skimmed the surface.

With the help of a Software Engineering Intelligence (SEI) solution, an engineering manager can more clearly identify at-risk work and potential blockers before standup, so they know exactly what to ask to get past surface-level updates. That means standup can look more like this:

Engineering Manager: Ok, I also see there were multiple discussions on the feature that required you to make a change in the code two weeks ago. Did the requirements change?

Dev: Actually, there have been bugs reported so I am adjusting my approach.

Engineering Manager: Ok, let’s grab some time this morning to walk through your approach step-by-step as this has been a tricky part of the codebase.

Because the manager came to standup with context on the PR in question, they were able to dig deeper and ask questions that uncovered potential risks. Both parties were then able to walk away from standup with clear objectives and next steps to keep the sprint healthy and on track.

There are many ways to structure standups, but one fact always rings true — the more prepared you are walking into standup, the more effective your meeting will be. Request a consultation to learn more.

Why a Strategy Matters

At the heart of every successful software engineering team is a drive for three things:

1. A culture of continuous improvement
2. The ability to move from idea to impact quickly, frequently, and with confidence
3. A software organization delivering meaningful value

These goals sound simple enough, but in reality, achieving them requires more than just wishing for better performance. It takes data, action, and, most importantly, a cultural shift. And here's the catch: those three things don't come together by accident.

In my experience, whenever a large-scale change fails, there's one common denominator: a lack of a cohesive strategy. Every time I’ve witnessed a failed attempt at implementing new technology or making a big shift, the missing piece was always that strategic foundation. Without a clear, aligned strategy, you're not just wasting resources—you’re creating frustration across the entire organization.

Step 1: Define Your Purpose

The first step in any successful engineering insights strategy is defining why you're doing this in the first place. If you're rolling out developer productivity metrics or an insights platform, you need to make sure there’s alignment on the purpose across the board.

Too often, organizations dive into this journey without answering the crucial question: Why do we need this data? If you ask five different leaders in your organization, are you going to get five answers, or will they all point to the same objective? If you can’t answer this clearly, you risk chasing a vague, unhelpful path.

One way I recommend approaching this is through the "Five Whys" technique. Ask why you're doing this, and then keep asking "why" until you get to the core of the problem. For example, if your initial answer is, “We need engineering metrics,” ask why. The next answer might be, “Because we're missing deliverables.” Keep going until you identify the true purpose behind the initiative. Understanding that purpose helps avoid unnecessary distractions and lets you focus on solving the real issue.

Step 2: Understand Your People

Once the purpose is clear, the next step is to think about who will be involved in this journey. You have to consider the following:

1. Who will be using the developer productivity tool/insights platform?
2. Are these hands-on developers or executives looking for high-level insights?
3. Who else in the organization might need access to the data, like finance or operations teams?

It’s also crucial to account for organizational changes. Reorgs are common in the enterprise world, and as your organization evolves, so too must your insights platform. If the people responsible for the platform’s maintenance change, who will ensure the data remains relevant to the new structure? Too often, teams stop using insights platforms because the data no longer reflects the current state of the organization. You need to have the right people in place to ensure continuous alignment and relevance.

Step 3: Define Your Process

The next key component is process—a step that many organizations overlook. It's easy to say, "We have the data now," but then what happens? What do you expect people to do with the data once it’s available? And how do you track if those actions are leading to improvement?

A common mistake I see is organizations focusing on metrics without a clear action plan. Instead of just looking at a metric like PR cycle times, the goal should be to first identify the problem you're trying to solve. If the problem is poor code quality, then improving the review cycle times might help, but only because it’s part of a larger process of improving quality, not just for the sake of improving the metric.

It’s also essential to approach this with an experimentation mindset. For example, start by identifying an area for improvement, make a hypothesis about how to improve it, then test it and use engineering insights data to see if your hypothesis is correct. Starting with a metric and trying to manipulate it is a quick way to lose sight of your larger purpose.

Step 4: Program and Rollout Strategy

The next piece of the puzzle is your program and rollout strategy. It’s easy to roll out an engineering insights platform and expect people to just log in and start using it, but that’s not enough. You need to think about how you'll introduce this new tool to the various stakeholders across different teams and business units.

The key here is to design a value loop within a smaller team or department first. Get a team to go through the full cycle of seeing the insights, taking action, and then quantifying the impact of that action. Once you've done this on a smaller scale, you can share success stories and roll it out more broadly across the organization. It’s not about whether people are logging into the platform—it’s about whether they’re driving meaningful change based on the insights.

Step 5: Choose Your Platform Wisely

And finally, we come to the platform itself. It’s the shiny object that many organizations focus on first, but as I’ve said before, it’s the last piece of the puzzle, not the first. Engineering insights platforms like Code Climate are powerful tools, but they can’t solve the problem of a poorly defined strategy.

I’ve seen organizations spend months evaluating these platforms, only to realize they didn't even know what they needed. One company in the telecom industry realized that no available platform suited their needs, so they chose to build their own. The key takeaway here is that your platform should align with your strategy—not the other way around. You should understand your purpose, people, and process before you even begin evaluating platforms.

Looking Ahead

To build a successful engineering insights strategy, you need to go beyond just installing a tool. An insights platform can only work if it’s supported by a clear purpose, the right people, a well-defined process, and a program that rolls it out effectively. The combination of these elements will ensure that your insights platform isn’t just a dashboard—it becomes a powerful driver of change and improvement in your organization.

Remember, a successful software engineering insights strategy isn’t just about the tool. It’s about building a culture of data-driven decision-making, fostering continuous improvement, and aligning all your teams toward achieving business outcomes. When you get that right, the value of engineering insights becomes clear.