Code Climate

codeclimate

When global circumstances required our team to go completely remote, we knew things would be tough. Team members wouldn’t just be working from home; they’d be working from home during a time of intense fear and uncertainty, with a myriad of new concerns and distractions. We expected that engineering activity would decline as a result, and we were understanding — as our VP of Engineering, Ale Paredes, explained during a panel on , “We're not trying to behave as if it's business as usual, because it's not business as usual.” But when Ale checked the team’s productivity metrics in , our engineering analytics platform, she was surprised by what she found. After we made the switch to a distributed workflow, many engineers actually started working more. Still, despite logging more time in the codebase, they were getting less done. To find out why the team wasn’t making progress, Ale dug deeper into the data. Not only did she find answers, she used that information to develop better ways to support the team. working remotely through the crisis Velocity Engineering Metrics Served as a Diagnostic Tool Ale and the engineering team regularly track certain key metrics in , using data about Pull Request Throughput, , and Incidents to get a sense of how they’re doing. They review this information on a bi-weekly basis, so they can address red flags as early as possible or replicate processes that are having a positive impact. When something appears to be trending in a concerning direction, the team drills down deeper into the data, then uses that information as a starting point for troubleshooting conversations. After the team transitioned to a fully-distributed workflow, they noticed that their Pull Request Throughput was significantly lower than usual. Velocity Cycle Time Knowing that the team was merging fewer Pull Requests than expected, Ale took a closer look at the stages of the coding process to find out why. This investigation included a look at: The time between a developer’s first commit and the opening of an associated Pull Request. If the team simply wasn’t pushing commits in the first place, it could be a sign that their attention was focused elsewhere, or that they were being sidelined by anxiety or emotional stress. If developers were coding but not opening PRs, they could be confused about project specifications. Time to Open: The period between when a Pull Request is opened, and when it’s picked up for review. A slowdown here could mean that physical distance was causing engineers to focus on their own work and deprioritize assisting their teammates. Time to First Review: The period of time a PR spends in the code review process. If PRs were getting stuck in code review, it could indicate a lack of alignment between members of the team. Time to Approve: The actual deployment process. A holdup at this phase could be the result of technical issues or a lack of confidence in new code. Time to Deploy: As she dug into the metrics, Ale saw that Time to Open was the source of the slowdown. The engineering team was clearly working — they were pushing commits, and actively coding — but they were completing a higher than usual percentage of Rework. Something was keeping the team writing and rewriting the same pieces of code, which concerned Ale. “Beyond the waste itself, which is not great, I worried that if we didn’t address the issue right away, it could impact team morale.” Improved Communication Helped Decrease Levels of Rework With this information, Ale approached the engineering team’s squad leads “to try to understand what was blocking the team, and to identify how we could work together to create a process that was more streamlined.” Through these conversations, Ale discovered that individual developers were getting hung up as a result of miscommunications and unclear specs. Though the team was having regular remote meetings, developers still lacked the information they needed to do their work. “People didn’t have the same amount of context,” Ale found. “We used to rely on the fact that we were all together in the office so that if I had something to say, the person next to me would hear it...our team is small enough that usually, everyone on the team has context.” Without a process in place for sharing this big-picture information, engineers were getting left in the dark. They didn’t always know how their work fit into the project as a whole, so they were making assumptions, some of which were incorrect. At the same time, “we noticed that people were using direct messages to communicate, so everyone had slightly different bits of information,” and developers were forced to continually revise their work as new information came to light. Armed with these realizations, Ale and the team were able to create new processes to combat misinformation and enhance transparency: Discussions were moved to a team public Slack channel, with particularly complex conversations happening in groups over Zoom. Decisions were logged in Jira, with each engineer responsible for adding relevant comments to any issues they own, so the rest of the team could reference them when needed. They created systems for intentional public communication. For each new feature, the team worked with Product to draw up a detailed spec document. These documents were then discussed at kickoff meetings for each new track of work so that everyone could see the details and ask questions. For projects that required more in-depth technical design, engineers would write a Request for Comment document and store it in markdown format in GitHub, so teammates could leave comments as part of the code review process. They leaned more heavily on documentation. Each week, the team wrote down their plans for the next few days and shared them with the rest of the team. They wrote down and shared their plans. Though she’s always done it, Ale made a continued effort to encourage senior engineers to use the team public Slack channel to discuss challenges and think through solutions, so that team members feel safer raising questions and admitting confusion. They fostered a culture of sharing. With the new processes in place, the team kept an eye on the metrics to evaluate their success. The Productive and Human Benefits of Increased Transparency The new processes helped increase transparency, reduce confusion, and boost productivity. In a span of four weeks, Rework fell from a high of 20% to just 6%. Over that same period, average PR Throughput went up almost 70%. But most importantly, engineers are now less confused and are finding more opportunities to collaborate. The emphasis on documentation and written plans offer the opportunity to ask questions at every stage of the process. And with everyone looped in, developers can lend a hand to people on other teams, something that frequently occurred when everyone was together in the office. Writing things down also has an unforeseen benefit — it’s helping the team avoid unnecessary meetings. While the team is remote, they’re using that extra time to connect on a more human level, building time into each standup to check in with each other, and carving time out of retros to talk about how they’re coping with the current situation. As Ale explained, “We were able to adapt our last retro to how we were feeling, instead of just focusing on the product process. We understood that was not what we needed to be talking about right now, that we need to talk about how we’re feeling and how we’re coping.” Ale expects the team will continue to see benefits from these new processes, even once they return to the office. Alignment has increased, communication has improved, and enhanced documentation will make it easier to onboard new team members. Plus, when the team reverts to their partially-distributed structure, they’ll do so with a greater sense of unity. As Ale explained, “We now have a lot more empathy for our remote team members.” If you’d like to learn more about how engineering analytics can help you support your team, join us for a free, 45 minute live webinar with Code Climate Co-Founder Noah Davis on Tuesday, May 5th at 1pm (EST). This webinar will focus on how to dig into engineering data from Velocity to improve the way you run remote meetings. Previously published at https://codeclimate.com/blog/how-our-vp-of-engineering-used-data-to-support-our-engineering-team-on-a-human-level/

How CodeClimate's VP of Engineering Used Data to Support Our Engineering Team on a Human Level

This Slogging thread by Arthur Tkachenko occurred in slogging's official #programming channel, and has been edited for readability. Arthur Tkachenko Mar 27, 2022, 11:05 PM Today I want to introduce a simple module for parsing CSV files Arthur Tkachenko Mar 27, 2022, 11:25 PM Recently I was exploring my old repository: https://github.com/Food-Static-Data/food-datasets-csv-parser Arthur Tkachenko Mar 27, 2022, 11:26 PM Inside I have a cool set of small modules, that helped me a lot. As my code is highly tied to those packages -> I need to pray for developers that build them, so I don't need to spend precious time. List of modules that I'm using: csv-parser fs lodash path path-exists shelljs Arthur Tkachenko Mar 27, 2022, 11:27 PM Why did I create this package? It's simple. During our work @ Groceristar, we came around a number of databases and datasets, related to "food-tech". To be able to extract that data and play with it -> you need to parse CSV files. Arthur Tkachenko Mar 27, 2022, 11:27 PM Arthur Tkachenko Mar 27, 2022, 11:28 PM Arthur Tkachenko Mar 27, 2022, 11:28 PM Arthur Tkachenko Mar 27, 2022, 11:29 PM Arthur Tkachenko Mar 27, 2022, 11:36 PM Link to the repository: Link to npm page: https://github.com/Food-Static-Data/food-datasets-csv-parser https://www.npmjs.com/package/@groceristar/food-dataset-csv-parser Arthur Tkachenko Mar 27, 2022, 11:44 PM I will also post updates about building modules for static data on indie hackers. While it didn't help with promotions a lot, founders are pretty positive people and their support really matters. Here is an org that I created few years ago: https://www.indiehackers.com/product/food-static-data Arthur Tkachenko Mar 27, 2022, 11:45 PM As usually, experienced developers might tell me that I'm stupid and CSV parsing is a mundane procedure. But I don't care. I realized that for a few separate projects we are running similar code. So I decided to isolate it. I did it a few times before I finally find a way to make it work as I like. And you can see how it looks right now. I can say, not ideal, but it was working fine for me. Right now I plan to revamp this package a little bit, in order to make it work with the latest versions of rollupjs and babel. Arthur Tkachenko Mar 27, 2022, 11:50 PM Arthur Tkachenko Mar 27, 2022, 11:58 PM While the idea is simple: connecting a dataset in CSV format, parsing it, and exporting data as you need it, while you need to make it work with 10 different datasets, things arent as easy as they sound in your head. CSVs not only related to food tech datasets. But for me was important to be able to use different datasets and easy to play with it. It makes other modules that we are building data-agnostic and more independent to a database/frameworks/logic. Basically, around this idea, we created and optimized like 13 repositories. Recently I created a separate organization that will be focused on those repositories only. Link: https://github.com/Food-Static-Data Later I plan to remove some repositories when they wouldn't be replaced by other, more popular, and stable tools. This current module can be useful for parsing other datasets too. But making it separate from the food tech topic isn't my task at this point. Arthur Tkachenko Mar 27, 2022, 11:59 PM And I was able to include and implement cool and important packages, like husky and coveralls. I can't say that I get most from them, but at the same time, it helped me to jump into the "open source ocean" that related to the GitHub rabbit hole that I'm still exploring for so many years. Arthur Tkachenko Mar 28, 2022, 12:00 AM and it's good to not just type another line of code, but also be able to see that your codebase is solid and nothing breaking it behind your back Arthur Tkachenko Mar 28, 2022, 12:02 AM Arthur Tkachenko Mar 28, 2022, 12:02 AM CodeClimate( ) helped me to explore and be able to take another look at how to develop things. https://codeclimate.com/ Arthur Tkachenko Mar 28, 2022, 12:03 AM Arthur Tkachenko Mar 28, 2022, 12:04 AM Arthur Tkachenko Mar 28, 2022, 12:05 AM Arthur Tkachenko Mar 28, 2022, 12:07 AM Yeah, codeclimate shows that I have code duplicates and ~50h of tech debt. Looks like a lot, right? But this is a small independent package. Imagine how much tech debt has your huge monolith project. Years of wasted time of developers, probably 🙂 Arthur Tkachenko Mar 28, 2022, 12:07 AM At some point i'll remove duplicates and it will reduce number of hours on this page. Arthur Tkachenko Mar 28, 2022, 12:10 AM Plus, usually, your product owner or CTO is busy and can't review code and be able to track things inside your code. CodeClimate can do some stuff for you. Just check those settings. Plus, they support open-source movement. So if your code is open and located on GitHub, you can use it for free. Arthur Tkachenko Mar 28, 2022, 12:14 AM Stretch goals are simple I want to invest some time into CI/CD stuff. At this moment i'll pick Travic CI. At some point i'll extend it, so when a new version of this package is published, i'll run it against our datasets and will see if something breaks or not. I also need to remove duplicated code that i was moved into separated packages but still present here, due to back capability. and it's also not cool to see JS code with all there csv files at the same repository. I need to came with idea about how to organize folders and make it easy to navigate. While it works for me - other people might find it very confusing. Arthur Tkachenko Mar 28, 2022, 12:17 AM We even did a great readme file with an explanation of how to run this package We collected a great number of datasets that can help a wast number of food projects. Some of them even sell the latest updates for money. Right now this module was tested with: - FoodComposition dataset - USDA dataset(i pick 4 major tables with data) - FAO(Food and Agriculture Organization of the United Nations) dataset This module is not just for parsing data, we also have a need to write files in JSON format with formatted data inside. Arthur Tkachenko Mar 28, 2022, 12:18 AM Show some love if you want more articles like this one! any activity will be appreciated. Arthur Tkachenko Mar 28, 2022, 12:18 AM Similar articles: - - - - https://hackernoon.com/introducing-a-simple-npm-module-with-email-templates https://hackernoon.com/how-i-started-to-build-react-components-for-email-templates https://hackernoon.com/organizing-an-advanced-structure-for-html-email-template https://hackernoon.com/open-sourcing-regular-expressions-for-markdown-syntax-module

Introducing a Simple Module for Parsing CSV Files

Gathering context and showing empathy may be the most difficult parts of a performance review, but they’re also the most important — this year, more than ever. Even in the best of times, . In the era of COVID, with team members already contending with external stressors and , a poorly-executed performance review is likely to be even more damaging to your team members’ morale. performance reviews can be harmful verging on burnout With a little extra care, leaders can avoid giving a review that focuses on business goals at the expense of the individual — and hopefully, can take a few additional steps towards boosting their team members’ motivation and well-being. After working with 1000s of engineering teams on improving performance, we've learned a few things about successful end-of-year reviews. We recommend that reviewers: Take measures to check assumptions Assume best intentions Contextualize the limited information available Be specific and Focus on coaching opportunities These strategies will help you give an effective yet compassionate review, and are worth keeping in mind any time you need to give constructive feedback. Check Your Biases and Assumptions With Data Most managers are that can hamper their ability to fairly and accurately evaluate your team members. But awareness isn’t enough. The most effective way to reduce bias is to . aware that they have innate biases check your instincts against objective data For example, performance reviews are particularly subject to recency bias. The last few weeks or even months of work loom largest in your memory, which means they are most likely to influence your opinion about your team member’s performance, even if they represent a small sliver of the past year. If your team member has been writing fewer commits than usual over the last month, you might remember them as writing less code for the entire year, Objective data can help you check that bias, as a quick look at your team member’s Commit Volume for the past year can confirm that their current drop in productivity is temporary and not representative of their performance as a whole. even if that is not the case. You can use data to check other assumptions as well. Let’s say one of your team members has been taking afternoons off to supervise remote learning or to care for an elderly relative. You might fall prey to negativity bias, a universal bias in which negative impressions — in this case, your team member’s truncated working hours — make a larger impact than positive ones. As a result, you might overlook your team member’s positive contributions to the team and assume that they have been less productive because they’ve been working fewer hours. But with objective data, you’ll know for sure. You might check their Pull Request Throughput over the last year and find out that, in fact, your team member has been just as productive than usual, if not more, because they’ve been hyper-focused during their limited working hours in an effort to get everything done. Put Everything in Context Of course, data doesn’t tell the whole story. It’s always important to put all quantitative data in context, but it’s particularly important now, when . With the right context, you can get a more complete picture of your team members’ circumstances, and gain a better understanding of their current needs. everyone is in need of a little extra compassion and support Let’s go back to the example of the team member who has been writing fewer commits than usual over the past month. It might be helpful to use that information to start a conversation and find out why they’ve had a hard time getting into the codebase. You might find out that schools in their area recently shut down, and they’ve been struggling to get into a new routine with the added responsibility of supervising remote learning. With that information, you can develop a plan to better support that team member, whether it’s temporarily taking some work off their plate or offering them a little time off until they can get their bearings. On the other hand, your conversation might reveal information that has nothing to do with their personal circumstances at all. For example, you might find out that the team member who has been logging fewer commits has been taking time out of their workday to help with onboarding new team members and improving process documentation. With that knowledge, you can have a more targeted conversation about your team member’s interests and professional goals. If it turns out your team member prefers working with new developers to writing new code, and find more opportunities for coaching and mentorship. you might be able to help them reshape their role And don’t forget — positive data needs context too. You might be pleased to find that a team member has been more productive than ever over the past year, with a consistently high Commit Volume and PR Throughput, but it’s still worth having a conversation about why that is and how it’s impacting them. That team member might reveal that they’ve been feeling overwhelmed and insecure due to the current economic and political climate, so they’ve been taking on extra projects and working long hours to ensure their job security. As their manager, you can use this information to help reassure your team member that their contribution is valued and to help take some of the pressure off. You might even want to discuss their priorities and reallocate certain tasks, so you can help your team member avoid . burning out Use Data to Provide Specific, Actionable Feedback The most . Data can help you focus your conversations on certain aspects of a developer’s workflow, or specific units of work, so you can more effectively coach each individual developer. effective feedback is specific and actionable For example, let’s say one of the developers on your team is consistently opening large Pull Requests. You could simply encourage them to “open smaller Pull Requests,” but that feedback might not be effective if they’re having trouble finding ways to break down their work. Instead, it can be helpful to identify some of their largest Pull Requests and bring them to your evaluation. That way, you can take a look at some actual Pull Requests together and discuss ways they could be broken down into smaller parts. With concrete examples and a bit of focused coaching, that developer will walk away from your conversation with actionable strategies for opening smaller Pull Requests, and you’ll be more likely to see them achieve the desired result. In cases where your team members are seriously underperforming to the point where their job really is at risk, it can be helpful to set clear, specific performance expectations. With easy-to-understand targets, that team member may have an easier time doing what they need to do to stay afloat. Think Beyond the Annual Review Even if you’re able to run objective, compassionate performance reviews that leave your team members with actionable feedback, It’s not always easy for a team member to speak up and ask for support, and it’s difficult for developers to keep growing when they’re only getting feedback once a year. annual performance reviews happen too infrequently to maximize their potential for positive impact. If you don’t use them already, consider making regular 1-on-1s part of your management repertoire. With frequent 1-on-1s, you’ll , and with more frequent check-ins, you’ll be able to more effectively support them through difficult situations, whether it’s a personal challenge, like a sick loved one, or a professional one, like a communication breakdown with a fellow team member. get to know your team members on a more personal level Re-Evaluate Your Evaluation Process If there was ever a year to re-evaluate the way you handle performance evaluations, this is it. While current circumstances may have generated extra pressure to meet business numbers, they have also created extra reason to be compassionate. As a leader, it’s your responsibility to ensure that business pressure doesn’t compromise your team member’s well-being, and to create the best possible circumstances for your team member to do their job. No matter what you do, some of your team members may be struggling due to circumstances completely beyond either of your control. It may not be the right time for them to boost their productivity or reach the next level of professional success, and that’s ok. Previously published at https://codeclimate.com/blog/performance-reviews/

How to Reshape Performance Reviews for a Difficult Year and Beyond

Continuous Delivery is the ability to ship code quickly, safely, and consistently, and it’s a necessity for teams that wish to remain innovative and competitive. It’s focused on delivering value to the user and starting that feedback loop early — the ideal state of Continuous Delivery is one in which your code is always ready to be deployed. Many engineering leaders think of as a workflow and focus on the tooling and processes necessary to keep code moving from commit to deploy. But CD is more than just a process — it’s a culture. To effectively practice CD, you need to: CD Convey the importance of CD to your team Create a blameless culture, one in which developers feel safe dissecting and learning from mistakes Facilitate alignment between business goals and CD. With the right culture in place, your team will be better positioned to get their code into production quickly and safely, over and over again. Explain why CD is important Processes fail when developers don’t understand their rationale. They may follow them in a nominal way, but they’ll have a hard time making judgment calls when they don’t know the underlying principles, and they may simply bend the processes to fit their preferred way of working. Code Climate’s VP of Engineering, Ale Paredes, recommends starting with context over process. Explain why you want to implement CD, reminding your team members that new processes are designed to remove bottlenecks, facilitate collaboration, and help your team grow. As they get code into production faster, they’ll also get feedback faster, allowing them to keep improving their skills and their code. Then, you can set that will allow you to track the impact of new processes. Not only will your team members understand the theoretical value of CD, meeting these new goals will help prove that it works. concrete, data-based goals Connect with individual team members Ale warns that when an individual developer isn’t bought into the idea of CD, they’ll “try to hack the system,” doing things the way they want to, while working to superficially meet your requirements. This may seem like it accomplishes the same goal, but it’s not sustainable — it’s always counterproductive for a team member to be working against your processes, whether those processes are designed to promote CD or not. She recommends using 1-on-1s to get a sense of what motivates someone. Then, you’ll be able to demonstrate how CD can help support their goals. Let’s say a developer is most excited about solving technical challenges. You might want to highlight that practicing CD will allow them to take end-to-end ownership of a project: they can build something, deploy it, and see if it works when they’re shipping small units of work more frequently. If another team member is motivated by customer feedback, you can remind them that they’ll be getting their work into customers’ hands even more quickly with CD. Creating a blameless culture Once your team is bought into the idea of Continuous Delivery, you’ll need to take things a step further. To create the conditions in which CD can thrive, you’ll need to create a blameless culture. In a blameless culture, broken processes are identified so that they can be improved, rather than to levy consequences. It’s essential that team members feel safe flagging broken processes without worrying that they’ll be penalized for doing so or that they’re singling out a peer for punishment. A leader can help establish that blamelessness in the way they communicate with their team members. Ale’s rules for incident postmortems clearly state that there is no blame. Names aren’t used when discussing incidents or writing incident reports because the understanding is that anyone could have made the same mistake. Convince the C-Suite Fostering the right culture on your team is essential to effectively implementing Continuous Delivery, but it’s not enough. CD also requires support from the top. If your company is looking for big, splashy releases every quarter, Continuous Delivery will be a tough sell. Frequent, incremental changes are almost fundamentally at odds with the roadmap that the organization will set out for engineering, and how it will measure success. To bring Continuous Delivery to an organization like this one, you’ll benefit from applying one of the core principles of CD: incremental change. You won’t be able to drive a seismic shift in one push. Instead, you might try Ale’s strategy and look for ways to introduce small changes so you can start proving the value of CD. For example, you might try automating deployments, which should cut back on incidences of human error and free up developer bandwidth for writing new code. Process may start you on your way to Continuous Delivery, but you won’t get far. Pair those processes with a culture of CD, and you just might reach the — the point at which each improvement yields benefits that motivate developers to keep improving. The Virtuous Circle Virtuous Circle of Software Delivery

The Importance of a Continuous Delivery Culture

On average, a software development team reworks about 26% of its code prior to release. Even after accounting for necessary changes, those wasted hours can cost a medium-sized business upwards of $4.7M a year. Still, when engineering leaders look to cut costs, they often look at departmental spending. Software licenses, discretionary expenses, and even salaries may come under scrutiny. But not all costs come with such a clear price tag — inefficiencies in the software development process are harder to quantify, but much more expensive. According to a 2017 DORA white paper, , the cost of Rework in software development is staggering, setting businesses of all sizes back millions of dollars a year. Forecasting the Value of DevOps Transformations Source: Forecasting The Value Of DevOps Transformations: Measuring ROI of DevOps , DORA, 2017. Unnecessary Rework, or code churn, is a significant source of waste across all industries. As the authors note, when organizations reduce their levels of Rework, they’re “essentially getting additional capacity without having to recruit and hire – just by improving processes.” Not only are they recouping the cost of wasted time – if they reinvest that time in the business, they’re realizing gains from those additional working hours. Though the costs calculated in the DORA report are astonishing, they’re also conservative. They account for the dollar value of wasted time, but the cost of Rework in software development extends beyond the cost of unproductive hours. Unnecessary Rework can also harm morale, which can lower productivity and make it difficult to retain talented developers. Using DORA’s formula, it’s possible to determine how much money your department is wasting on unnecessary Rework. If you can find ways to evaluate, diagnose, and reduce your levels of Rework, you can begin to make a dent in one of your largest hidden costs. Identifying Unnecessary Rework in Software Development Information about your team’s Rework is already available in your VCS. Using , you can analyze Rework at both the team and individual level and begin to observe trends. When you’re just beginning to tackle Rework in your organization, start by establishing your team’s baseline. How much Rework is normal for your team? For an individual? an engineering analytics platform You can use that information to identify teams or individuals with high levels of Rework relative to the rest of the department. It can also help you spot any general organization-wide upticks. These deviations from your baseline represent anomalies worth investigating, though it’s important to note that your investigation won’t always reveal waste. Some Rework is expected, even necessary — and in some cases, avoiding Rework for the sake of bringing your numbers down will only convert that cost into technical debt, which you’ll pay for later. Through conversations with your team, you’ll be able to put your observations in context and determine which Rework is anticipated and which needs to be addressed. Source: Velocity . Green highlights high performance, while red indicates an area in need of improvement, relative to the rest of the team. Rework at the Individual Level Let’s say you’ve identified a developer whose Rework levels are higher than the rest of the team. Check that observation against what you already know about their circumstances. If the developer is a recent hire still getting familiar with the codebase, or a team member working in a new programming language, it’s reasonable to expect higher-than-usual levels of Rework. If this number doesn’t decrease over time, you can treat it as a coaching opportunity. Rework is a leading metric, and high Rework levels can signal that additional hold-ups will appear further down in your development pipeline. Use specific units of work as a starting point, and talk to the contributor about their biggest stumbling blocks. Together, you can develop a strategy for improvement, like arranging for a pair programming session with a more senior member of the team. Rework at the Team Level You can apply the same strategy to teams. When you notice that Rework is trending upward — on one team or across the organization — use that as a starting point for conversation. It can be helpful to bring specific units of work to your retros or stand-ups, so you can kick off the discussion around something concrete. Through these conversations, you may learn that the team has been struggling with unclear technical documentation, or suffering through . From there, you can work together to address the issue. A team whose Rework is a result of poor documentation may benefit from taking some time to clarify product specs, while one dealing with a lack of communication may benefit from opening new channels for sharing information. breakdowns in communication Set Targets to Decrease Rework Once you’ve begun to evaluate your team’s Rework, you can use that information to towards those goals. Set a target that is ambitious, but achievable, for your team. If you want to get to 20% and you’re currently at 30% Rework, it might be productive to aim to get to 20% in stages, rather than all at once. set targets and track progress What Will You Do With Your “Free” Time? Cutting down Rework is more than just a cost-saving measure. It’s a chance to reinvest in your department without spending money. Time that used to go to waste can be used for innovation. Developers who were previously frustrated by their inability to make progress will be motivated by the opportunity to add value, and will be more likely to stick around. With a stable team and more hours in the day, your department will be able to make an even bigger impact. Previously published at https://codeclimate.com/blog/rework-costs-millions/

Rework Costs Your Company Millions — How to Cut Back?

Processes are essential for effective management. They keep people in sync, making it possible for team members to come together and achieve a shared goal. But they’re also dangerous. Processes can create the illusion that things are running smoothly because they’re moving along according to the shared understanding of how they’re “supposed to” run. — the idea that by adding consistency and predictability to a shared workflow, a given process is inherently valuable. Too often, process becomes canon. A team develops an effective way of doing something, then returns to that framework indefinitely, long past its expiration date. This is the Fallacy of Process As processes grow stale, they become red tape, increasing friction rather than removing it. That friction is more than just a hassle; it can be incredibly expensive — inefficiencies result in lost productivity, and frustrated developers are more likely to seek new roles elsewhere. Just as a good process can multiply your team’s productivity, a bad, broken, or outdated process can have a compounding effect, costing your department more than any line item on its budget. , Rands and co-host Lyle Troxell, Senior Software Engineer at Netflix, propose the idea that between total entropy and complete control. For a process to be valuable, it needs to live somewhere between the two extremes. On their podcast every process lives somewhere on a spectrum They suggest that the problem with process starts with attitude, and they recommend that managers: Treat each process like a living, breathing thing. Recognize that just because something works well now doesn’t mean it will in the future. Work to understand the “why” of each process — and include it in documentation. If it’s difficult to articulate why something is done a certain way, it may be time for a change. Evaluate processes frequently, and improve them when necessary. Managers at all levels would do well to heed this advice. But it can be difficult to and honestly evaluate processes when you’re not the one tasked with implementing them. Still, it’s essential — the farther a broken process strays towards one end of the spectrum, the more it’s likely to cost you. So, as a leader looking to evaluate and optimize your team’s processes, where should you start? identify sources of friction Software development pipeline model courtesy of Alexandra Paredes. A can help you get your bearings. Start big — map out how work should flow through your software development pipeline, for instance — and then share that model with your team. Solicit their feedback, and pay careful attention to any points of confusion or disagreement. If your mental model doesn’t align with your team’s assumptions, it may indicate that a process is broken or that your documentation needs to be improved. Create a Mental Model. mental model Once your mental model reflects your team’s understanding of how things work, you’ll need to confirm that those expectations are in line with reality. Engineering metrics are a powerful way to get that gut-check; about how things are going. When a metric doesn’t align with your expectations, it’s a sign that you should dig deeper and get more context from your team — you may find a process that’s ready for a refresh. Use Data to Check Your Expectations. objective measurements allow you to test your hypotheses Take your list of ineffective processes, and identify the most problematic ones. Which are the biggest sources of frustration for your team? Which cause the biggest holdups? Which have a cascading effect, causing more blockages down the line? These are your most expensive points of friction and the ones you should focus on fixing first. Maximize Your Impact. Talk to your team about your broken processes, and ask how they’d fix them. Even if you think you’ve found an obvious solution, be sure to get feedback — if your team isn’t on board with a new process from its inception, it’s more likely to become a source of friction. Draw Up A New Plan, And Get Feedback. Processes are not static. They need to evolve as the circumstances around them change. Keep looking for ways to optimize your processes, and prevent them from becoming blockers. Repeat. Continually evaluating and revamping your processes is the only way to keep them fresh and effective, and to ensure you’re not paying for processes that exist for process’s sake. Of course, there’s a certain paradox inherent in proposing a new process for fixing old, broken processes. Adapt it, change it, and make it work for you. Anything less would just be falling prey to the Fallacy of Process. Previously published at https://codeclimate.com/blog/the-fallacy-of-process

Managers: Beware the Fallacy of Process

Preparing for a board meeting is a stressful experience for everyone. For many CTOs, it’s also an exercise in futility, trying to zero in on engineering KPIs that accurately represent everything that’s happened in the department. The information that usually makes it to the board deck — information on completed features and incident reports — doesn’t tell the whole story. A list of features shows what the team accomplished, but doesn’t reveal anything about how the team works. It can’t reveal process issues that need to be addressed or highlight challenges the team has overcome. Similarly, incident reports might illuminate problems in the codebase, but they’re devoid of context about how the team is dealing with those issues. Other departments have self-evident, objective KPIs. Sales, for example, can walk through their pipeline from demos booked to contracts signed, using objective measurements to chart their department’s progress over time. Engineering leaders, on the other hand, must get creative to provide that level of clarity. You’ll need to think carefully about the story you want your slides to tell, then choose engineering KPIs that map to those specific insights. When considering a metric, we recommend asking: Will this demonstrate the department’s success (or lack thereof)? Does this highlight something interesting or unexpected, and start a conversation? Will this help me ask for advice from the board? These parameters will help you select the right data to drive productive conversations, so you can walk away with actionable guidance from the board. Start with Engineering Success Metrics To convey big-picture information, start your presentation with engineering success metrics. Success metrics speak to outcomes; they measure the results your team is getting. In engineering, there are two aspects of success: planning and execution. Engineering decks usually include feature lists, which speak to your team’s ability to plan. But most engineering decks stop there. To dig into execution — your team’s ability to consistently ship projects — you’ll need another set of success metrics. When choosing success metrics that highlight execution, look for metrics based on objective data rather than subjective measurements like story points. With objective data, you’ll be able to track progress across teams, projects, and quarters, and for your department. Use metrics like: set more effective goals - A count of the engineering team’s deploys within a given period of time, Deploy Volume can help quantify the engineering team’s capacity. Deploy Volume - The number of Pull Requests merged over a period of time. Similar to Deploy Volume, PR Throughput can help you quantify how much the engineering team is getting done. PR Throughput - The time between the first commit logged in a Pull Request, and when that Pull Request is merged. Cycle Time acts as a proxy for engineering speed and can help you communicate how quickly the team is moving. Cycle Time Drill Down with Revealing Engineering KPIs After you report on success metrics, you’ll want to dive into additional metrics that provide critical context and perspective. Think about what you know to be true for your team, and then pick the data that will help you illustrate that to the board. You might want to include information that reveals the impact of a key decision or highlight a specific data point that raises an important question for discussion. Be open to all kinds of data — both quantitative and qualitative — and consider pairing multiple metrics to add dimension, or to answer questions before they arise. To determine which additional metrics might be useful, ask yourself: What did we promise the board at our last meeting, and how can we represent whether we made good on that promise? What took up a lot of engineering time this quarter? For example, were you making a big security push, focused on new features, or working through technical debt? What big changes or strategic decisions did we make this quarter? For example, did you increase headcount, initiate a re-org, or change an aspect of your review process? Your answers will be different every quarter, and they won’t always be noteworthy enough for the board. But your line of questioning might also uncover something that is important to share and not already covered in the deck. For example, let’s say at last quarter’s board meeting, you discussed implementing a support engineering rotation. This quarter, you might want to show the board that it’s having a positive impact on the team’s ability to resolve customer issues. To do that, you could report on the Issue Cycle Time of Escalations, which measures how long it takes for an escalation to be addressed once it’s opened. Though highly specific, this software development metric would demonstrate the success of the support initiative. Put Engineering Metrics in Conversation Putting metrics in conversation with each other can also help paint a more complete picture of what’s happening on your team. For example, it might be useful to share the engineering department’s PR Throughput, coupled with incident data. Either one of these metrics would be useful in isolation, but taken alone, a high PR Throughput might raise the implicit question: is the engineering team sacrificing quality in order to keep deployment high? By pairing PR Throughput with incident data, you’d be able to demonstrate that the team isn’t solely focused on deployments, they’re also consistently delivering quality code. You might also consider pairing metrics to demonstrate the impact of a strategic decision. Let’s say you recently hired three new engineers. You might want to share PR Throughput, paired with Active Contributors, to illustrate the team’s increasing output as the newly onboarded engineers begin to contribute more and more to the codebase. Most board meetings include a lot of anecdotal evidence from the engineering department. The inclusion of objective metrics can help you show the board exactly what’s happening on your team, so they can participate in the conversation more effectively, and offer up more useful guidance. Make Board Meetings Work for You The goal of a board meeting is to provide vital context so that the board can do what it’s there to do — offer advice and help with key strategic decisions. Subjective metrics and flawed measurements might feel like relevant updates, but they won’t reveal enough actionable information about what’s going on in your department. Think about what you want to get out of the board meeting, and then choose the data that provides essential context for those conversations. Previously published at https://codeclimate.com/blog/engineering-kpis-board-deck/

The Most Important Enginnering KPIs for Your Board Deck

When your team is building a software product, the majority of the work that they do is invisible. As a manager, you have to rely on in-person cues for blocked work or frustrated engineers. When they move to a remote workflow—your team also becomes invisible, and all those critical signals are dropped. In-person, you might notice: Nonverbal clues during stand-ups or retros Frequent interruptions as developers are pulled into meeting after meeting Tension between team members as they work through problems Acting on these signals is one of the most important ways you can help your team. You might say: “I noticed you seem frustrated each time you worked with Jack—is everything okay?” Or “I noticed that you’ve been helping the marketing team a lot, do you have too much on your plate right now?” When you transition to a remote workflow, you lose indicators that anyone is stuck, demotivated, or overworked. To adjust, you have to find new ways to broaden the now-limited purview that remote work allows. Signals to Remain Context-Aware From Afar When thinking about productivity or output, many software leaders think in terms of features or story points. They get a general sense of how things are moving (or not moving) based on whether these features are getting completed. But these metrics are lagging indicators, and they’re not diagnostic. If you know that you’ve shipped fewer features one sprint than you did in the previous, you have no insight into what you can do to improve things. Fortunately, we can derive much more granular signals for the speed and effectiveness of software development from the systems in which engineers already work. Data from how a developer works in their version control system, such as Commit Volume, Code Churn, or Pull Request Cycle Time, better clues you into how your team is working in real-time. These metrics are imperfect (as all metrics are), but they give you much more to work with in terms of diagnosing process problems within your newly-distributed workflow. Below, we’ve recommended a set of metrics that you can look at on a daily, weekly, and monthly basis to stay connected with how your team is working. Daily Signals for Stuck Work The most imminent threat to an efficient and happy remote team is stuck work. An engineer might be stuck because they are unsure of how to implement a change, because they’re unfamiliar with a portion of the codebase or for a number of other reasons. Any unit of work that isn’t moving through the Software Delivery Process quickly enough is a signal for you to check in. Look out for: Are team members working incrementally? Are they working on a particularly tough portion of the codebase? Infrequent pushes: Are team members reworking the same lines of code over and over again? Is there clear communication surrounding feature implementation? Rework: Are there Pull Requests that have been open for more than three business days? Is this causing multi-tasking? Long-running Pull Requests: Is a single Pull Request taking up the attention of several engineers who may be in disagreement? Pull Requests with 3+ participants: Are there Pull Requests that have been passed back and forth between the reviewer and the author several times? Pull Requests stuck in code review: shows all work in progress. See at-a-glance the Pull Requests that are most likely to impede your team. If you look at these signals with your team, you’ll have a shared understanding of how things are moving and where someone might be stuck. This data will take the pressure off developers to raise their hand during when something’s off track, and enable you, as a manager, to know when you can step in and help. Velocity daily stand-ups Weekly Signals for Goal Setting Once you’ve started tracking daily signals to keep your team on track, you can take a step back and start looking at how your engineers are working. If individual engineers are spending days working through a problem on their individual device, then opening huge Pull Requests that are perpetually getting stuck in the review process, your team will constantly feel stuck and frustrated. Agile and Continuous Delivery workflows demand that team members commit frequently, work in small batches, and limit work in progress. These habits set in motion what we call the : Virtuous Circle of Software Delivery Building these habits is crucial to minimize the risk associated with merging a PR and decrease the chances that an individual unit of work will get stuck in the process. For this, we recommend working with team members to set up process SLAs for good collaborative practices every week. Then, during retros and 1:1s, developers can work through concrete examples of when something went off track. You can set targets for things like: Can we agree that 95% of PRs should be successfully merged? We’ll investigate PRs that were closed or abandoned. Pull Request Success Rate: Can we agree to get to code reviews within 8 hours for 80% of Pull Requests? We’ll look deeper into PRs that couldn’t be reviewed quickly. Pull Request Time to Review: Can we agree to keep Review Cycles under 2 for 95% of Pull Requests? We’ll look into any PRs that get passed back and forth between author and reviewer multiple times. Pull Requests Review Cycles: Can we agree that 70% of the work should be done by at least 50% of the team? We’ll investigate deeper if just a few individuals seem to be doing most of the work. Workload Balance: Velocity’s Target feature lets you set SLAs to help hold your team accountable to their goals. Naturally, you don’t need to look at all of these metrics right away—just pick one or two that represent commonly reported issues. Selecting a granular metric, like Workload Balance, will be a much more effective indicator of what’s going amiss than a metric like Features Completed. Over time, your team can build habits that minimizes the opportunity for work to get stuck and slow down the team. Monthly Signals for Continuous Improvement Once you've identified signals that can point you towards daily and weekly improvement opportunities, you’ll want to start looking at your processes end-to-end to ensure that they’re working for, not against, your team members. First, you’ll want to make sure your processes work. If you’re working in a traditional Git workflow, you’ll want to make sure that PRs are moving along the “happy path” from Open to Reviewed to Approved to Merged. Any PRs that skip steps are working outside your process and represent opportunities for deeper investigation. Next, you’ll want to see how well this process is enabling a low time-to-market. If it takes days or weeks for changes to get into the hands of customers, your team will have a hard time quickly mitigating issues in production, and, ultimately, keeping up innovation. For this, you’ll want to keep an eye on your team’s delivery Cycle Time, or how long, on average, it takes PRs to go from a developer’s laptop to being merged to production. Velocity lets you visualize the journey of your Pull Requests from open to merged. Below, you can see metrics that represent constituents of this journey to better diagnose slowdowns. A that’s short and consistent is an indicator that your team is working with little friction, and your processes are enabling rapid innovation. If your Cycle Time is spikey, you’ll know to look into the units of work that make up a particularly high week. If your Cycle Time seems consistently high, you’ll want to to see, specifically, which processes or practices are dragging down your speed. We recommend looking at: Cycle Time break it up into components How much time passes between the earliest commit and the opening of a Pull Request? Time to Open: How much time passes between when a PR is opened and when it is first reviewed? Time to First Review: How much time passes between when a PR is opened and when it is merged to production? Time to Merge: Comparing these side by side will help you see where in your process your developers are being slowed down. When your team moves the needle and improves Cycle Time, it means you’re working together to boost the efficiency of the development process and to accelerate innovation. It’s important to communicate and celebrate success surrounding this metric to encourage continuous improvement on your team. Remote Engineers Deserve Great Leaders An unexpected transition to remote work is one of the most trying experiences for many software engineers. The already-isolating job of writing code becomes even harder when team members can’t chat or take breaks together. Leadership that is disconnected or not aware of all the challenges that they’re facing can be the final nudge that can disengage a team member. Fold in just a few extra signals to stay aligned with engineers and lend a hand when they need it most. We’ve worked with many organizations to help them smooth the transition from on-site to remote workflows. During this particularly difficult time, we’re giving away our analytics product, along with data coaching and support, for free for 45 days . Previously published at https://codeclimate.com/blog/the-essential-data-for-leading-a-remote-engineering-team/

The Essential Data for Leading a Remote Engineering Team

“Effective engineering leadership is being outcome-oriented,” says Kickstarter’s Mark Wunsch. When Mark first joined Kickstarter as VP of Engineering, one of his first decisions was to re-organize the engineering department, based on business-oriented objectives. Each 3–7 person scrum team focused on a different “essence,” or a different customer-facing part of the product. This helped engineering understand their work from a business perspective. Mark tells us, “The objective is not to ask, ‘Is the code good?’ but to ask ‘Is Kickstarter good?’” The engineers’ perspective, however, was difficult to communicate with leadership. The engineers were constantly bogged down by problems that were invisible to non-technical colleagues, such as legacy code. Kickstarter has been around for about 10 years, so a big portion of the codebase was troublesome to work with. Mark told us, “To an engineer, it’s so obvious when a piece of code is brittle, but it’s really hard to advocate for putting engineering resources into solving technical debt.” Mark decided to use metrics to further align engineering and leadership. Diagnosing technical debt with data Every developer knows that legacy code undoubtedly slows down engineering. But taking weeks away from shipping new features compromises how much new value the company is delivering to customers. Before making a case for refactoring to leadership, Mark decided to do a deep dive into where technical debt was slowing down the team. He used engineering analytics tool to learn how each engineering team was working and where they might be getting stuck**.** Velocity Mark started by looking at his team’s weekly throughput, as measured by merged pull requests. Whenever the throughput dipped significantly below their average, he’d know to investigate further. Seeing a low Pull Requests/Merged at the end of the week can be a red flag a team was stuck. Unlike subjective measures that are common on most engineering teams, like story points completed, Velocity metrics are represented by a concrete unit of work: the Pull Request. This enables Mark to objectively understand when a scrum team is really bogged down, compared to the last sprint or last month. Once he spotted productivity anomalies, Mark would pull up a real-time report of his teams’ riskiest Pull Requests. Pull Requests that were open longer and had a lot of activity (comments and back-and-forths between author and reviewer) were at the top of the list. An example of Velocity ’s Work In Progress which shows the old and active pull requests that may be holding up the team. Because trickier parts of the applications tend to require more substantial changes, pull requests that are most “active” often point Mark to the most troublesome areas of the codebase. After a few weeks of investigation, Mark was able to find concrete evidence for what his intuition was telling him. “The data showed that we were consistently slowed down because of legacy code,” said Mark. Bringing transparency to engineering practices During meetings with the executive team, Mark could now point to weeks with less output and prove that technical debt was impeding the engineering team from their primary business objective: continuously delivering new features. To communicate how the team was doing, he’d present a Pull Request throughput chart with a trend line: A Velocity report showing Pull Requests Merged/Day, over the last 3 months. This helped leadership visualize how much Kickstarter was growing in their engineering efficiency but also opportunities for further improvement. Mark also shared Cycle Time (i.e., how quickly code goes from a developer’s laptop to being merged into master.) A Velocity report that shows the fluctuation of Cycle time, over the last 3 months. Cycle time was a great indicator for how much trouble it was to make a change to the codebase. High cycle time would often correspond to low output a day or two later, showing that some form of obstruction existed for a developer or team. These two charts, along with Mark’s summary of his more technical findings, aligned all of leadership around scaling back on new features temporarily and dedicate more time to refactoring. Bridging engineering and leadership After spending time investigating what legacy code was slowing down the team, Mark was able to take a strategic approach to how they tackled technical debt. Rather than jump on the opportunity to fix anything that looked broken, he could have teams focus on the biggest productivity blockers first. Engineers were happy because they had the time to rework the legacy code that was constantly slowing them down. Leadership was happy when they could see long-term improvements in engineering speed. Six months after refactoring, Kickstarter saw a 17% increase in Pull Requests merged and a 63% decrease in Cycle Time. It was a win-win-win. Mark tells us, “Being able to talk about technical debt in the same way we talk about business metrics is incredibly powerful.” If you want to , . learn exactly how much technical debt is slowing down your own engineering team try Velocity free for 14 days Originally published on codeclimate.com

How Kickstarter’s Mark Wunsch Used Engineering Metrics to Make a Case for Refactoring

Thousands of happy customers validated our software– but dogfooding validated our values. Velocity A couple of years ago, our engineering leaders were anecdote-driven, like just about everyone else in the industry. We knew how much progress an engineer had made on a new feature because we asked. We knew why we missed a deadline for launching a new feature because we discussed it in our retros. But we couldn’t answer simple questions like: Is our efficiency increasing or decreasing over time? What work slows us down and where is the biggest opportunity to improve? Which developers on my team are stuck, right now? Even on a small development team, the insights that we had into our own productivity were limited. Last year, we launched Velocity, an designed to help teams big and small with exactly the issue that we, ourselves, experienced. In the process of iterating and improving the platform, our Engineering Manager, Ale Paredes dogfooded our app. She used each feature from Velocity as soon as it was built and has experienced the benefits of data-driven engineering first-hand. engineering analytics tool Armed with Velocity, she addressed burnout, improved remote collaboration, and helped restructure the engineering team. The result was an 83% increase in productivity, and a healthier, more engaged dev team. Here’s what dogfooding has done for Code Climate. Velocity We Ditched Flat and Near Doubled Our Efficiency Flat structure doesn’t scale. There comes a point along every engineering team’s growth where the same set up that once built camaraderie and a shared purpose now fuels disengagement and a lack of focus. Ale first started noticing that disengagement during daily standups. Some people were zoning out; others were on their phones. Almost no discussion was happening. It was 20 minutes of engineers taking turns speaking, one by one. When she brought this up in her 1:1s that week, she found that the team was in unanimous agreement: meetings were inefficient and taking up too much time. Ale checked her hypothesis against the metrics by looking at Pushes per Day over the last 6 months. A custom report Ale built to see how Pushes per Day has been affected as the team scaled. Velocity Velocity gave her confirmation that the team’s efficiency had, in fact, been steadily decreasing over the past four months. Ale took this insight back to the leadership team, and together, they decided it was time to ditch flat. Software development is inherently collaborative, and if engineers have too many co-workers to support, they can’t feel invested in one another’s work. We decided to break up the ten-person team into groups of three or four engineers. We hypothesized that breaking up teams by would help individual engineers focus on less tracks of work. As a result, meetings would suck up less time and be more engaging, as smaller teams only hash out problems relevant to the few people involved. Bezo’s 2-pizza rule When Ale implemented this change, the feedback was overwhelmingly positive. Engineers were doing more of what they liked (coding), and less of what they hated (meetings). Over the course of several months, the metrics corroborated what the team was feeling: we started moving much faster. A custom report Ale built to see how Pushes per Day has increased since the re-org. Velocity We went from an average of in November to an average of in January, an 83% increase. 12 pushes/day 21 pushes/day We Coached Remote Team Members for Better Collaboration Agile software development relies on strong communication, and, in many cases, frequent face time, so managing team members that are an ocean and three time zones away is nontrivial. It’s hard to perceive frustration through Slack. It’s hard to understand workload through Zoom. Ale made a concerted effort to check in with remote team members and find out what’s going well and where they might be in need of coaching. But not everyone is an open book– many of her remote team members hesitated to bring up troublesome pull requests or bottlenecks during these meetings. To find a starting point for these conversations, Ale started looking through a handful of contributor metrics on a weekly basis. She would pay particular attention to overall throughput (# of PRs merged), rework (how often developers work on their own recently merged code), and cycle time (how long it takes code to go from a developer’s laptop to being a merged PR). By putting together a chart in Velocity, she started noticing a pattern. Remote developers had a significantly higher cycle time than HQ team members. A custom report Ale built to see Median Cycle Time by team member. Velocity Before a 1:1 with Legolas Greenleaf, Ale dug deeper into Velocity to see where, exactly, in the PR process contributors were getting stuck. A chart that shows how contributors are performing on metrics compared to the industry standard. Velocity Ale discovered that Legolas was spending a lot of his time working on code on his laptop before opening up a Pull Request and getting his work looked over. The next time they sat down, Ale discussed the trend she noticed. The remote team member was able to speak more specifically about what has been slowing him down and what challenges he was facing. In their conversation, she guided Legolas towards learning how he could’ve better approached some of the last few PRs. Together, they discovered the heart of the problem was that his PRs were too big. Splitting up projects into smaller pieces was a work habit that the HQ team had heard a ton, but the distance between Ale and the remote workers meant they weren’t aligned in terms of best practices. The data brought Ale’s attention to the problem, and gave her something objective to work off for her coaching sessions. We Prevented Burnout in our Engineers Meeting deadlines and building great products isn’t the only measure of a good team. We also want engineers to be engaged and not overworked so that our pace is sustainable. Too often, however, burnout is impossible to sniff out until it’s too late. Last December, the team was on a tear. We were shipping features every other day, we had redesigned most of the pages in the application, and everyone was stoked about all the cool new stuff we were building. Everything seemed great. During her weekly check-ins, however, Ale started noticing a trend. Engineers were excited about their work, but everyone seemed to be feeling a lot of pressure to get features shipped– even though we were ahead of schedule. One senior engineer mentioned that he barely had time for code reviews. Other team members started neglecting pair programming in favor of spending more time getting stuff out the door. Ale used Velocity to take a look at what the team had on their plate: ’s Activity Log showed leadership how much individuals were working. Velocity She noticed that some developers had so much activity, it barely fit in their row. In a few cases, we were even pushing on weekends, which is highly unusual for our organization. Looking through all the PRs and reviews the engineering team was churning out, Ale became suspicious that people were working overtime. She put together a report using Velocity’s Reports Builder to see how many pushes were made after 8pm each week: Ale built a custom Velocity report to see who was working late hours. During the last two weeks, the team had been working late hours more than they had in the previous three months combined. Ale brought this data to the leadership team and was able to successfully advocate scaling back work and giving the engineering team a well-deserved day off. Now, Ale checks these dashboards regularly and sends out a monthly survey to check in on how work is distributed and how team members are feeling. Measure and Mobilize Metrics are not everything. Metrics didn’t help Ale notice that engineers were disengaged during meetings, or that remote team members weren’t voicing problems. Instead, metrics helped her check her intuition with more transparency into what’s going on. They also enabled Ale to verify that the changes she made generated an improvement in our productivity. This gut-check was invaluable in helping us move faster and communicate better, both inside the engineering team and with the organization as a whole. If you want to learn more on how Velocity can let you see deeper into your team’s work habits (and help you move at least 20% faster), sign up for a demo . here Originally published at codeclimate.com .

Stories, News & Mentions about CODECLIMATE

Codeclimate’s Stories on HackerNoon