Resilient Engineer: 3 Key Tools for Growing Data-Driven Development Teams

Nearly a decade ago, I stumbled across the oath of non-allegiance and like many others, signed it. A few years ago at another company, one of my mentors (Tim Heller) reminded me to take it again. My mindset already nearly mirrored the philosophy behind it. No ideas or tools should be shunned or pushed away simply because of their origin. Likewise, no processes should be married to specific tools or frameworks with rigid inflexibility.

I’ve carried that mindset throughout my career and have strived to build flexible processes that were not anchored or tethered to a specific tool, product, or methodology. This means that sometimes achieving the fastest outcome was done through using sticky notes, or regular Notepad, or even Vim. Every once in a while though, either my team or myself stumbles upon something new that just can’t be passed up. It may be new software, new ideas, new frameworks, or new insights.

There are three such tools that our team here at CBG has stumbled across that have increased our joy of software development or are providing such valuable insights to our development process. Team members like Davis Hansen, Spencer Judd and Angela Tillman make the insights and actionable results enjoyable. I wanted to share them here so that other teams may benefit from them.

Clubhouse

For most of my development career, I’ve been using Atlasssian Jira for project management within software development teams. I can’t say that I loved it all the time, though I have felt the wind shift a bit in later years with them becoming a bit more modern and nimble in their approach to project management.

About a year and a half ago I stopped using Jira when I discovered a tool called Clubhouse while wandering through the last days of AWS re:Invent 2019 in Vegas. On the surface, it seemed like Clubhouse took the best of Jira, sticky notes, and human behaviors and bundled them all up into what I would call the best project management tool out there for software development teams. It’s funny to say this, but it’s actually quite fun to use.

How is it different?

With Clubhouse, the approach to project management feels so lightweight compared to other tools. Collaborating with team members and cross team members is simple, doesn’t require complex, cross-team permissions, and planning, building, and measuring are all features with first class citizenship. My team is simply can get things done faster with respect to project management using clubhouse.

Switching between stories, epics, sprint iterations, custom reports, and a newly added feature called quarterly roadmaps is generally done with a simple one or two clicks of the mouse. This helps because it provides context switching quickly to see how work may fit into overall initiatives.

Workflow customizations

Our teams aren’t locked into rigid workflows, complex workflow design tools, and one-size-fits-all Kanban boards. Our teams can customize them to fit the needs of their flows and their requirements and methodologies, depending on the team.

With the newly added feature of teams, combined with the already existing epics, milestones, and roadmaps, team members from all across our company can form work effectively together to achieve our company priorities and initiatives.

Highly friendly reports

One of the first things that initially caught my eye was how seamlessly integrated data insights were embedded in with the tool. Burndown charts were automatically generated, time and workflow state graphs, cycle and lead time charts, and other reports were easily available within the tool so that my teams didn’t need to spend hours creating other reports in other tools for executives. We love that we can use the reports generated by the tools we already use on a day-to-day basis.

Data & system integrations

The Clubhouse API makes it really easy to use out of the box integrations for tools we already use, and also author our own integrations that connect with their API. We have several automated workflows now that connect to the Clubhouse APIs through Microsoft’s Power Platform automated cloud flows and bots. This is been super helpful for our team to help them automate complex manual processes.

Stories, epics, milestones & roadmaps

In Clubhouse, everything starts with a story. A story needs to be created in a simple project and it can be done quickly. You can create a chore, feature, or bug, and define it’s metadata very quickly. Those stories can be saved as templates for frequently used formatting or just use custom markdown to add some more content on-the-fly.

We’ve found that we’re able to easily track our company initiatives and the associated progress through epics and milestones. It also helps our development teams visualize how their everyday tasks are helping push the needle forward on those larger initiatives.

Iterations & Kanban boards

Iterations in Clubhouse are top notch and they can be used to quickly prioritize and track what a team is currently focusing on and what time frame. Within the iterations, reports are generated automatically and give fantastic insights to the conversations that a team needs to have.

On the Kanban boards used within iterations, the typical drag-and-drop feature is there for manual moving of stories based on some status change. What our team has chosen instead is to use the clever GitHub integration so that pull requests and other git activities automagically move stories along in the workflow to the proper state. All boards and stories are updated in real time so the data is always accurate.

From a “Dev Exec” perspective, the visibility gained from Clubhouse has been such a welcome present. Velocity and burndown charts, cumulative flow diagrams, cycle and lead times, all of these are insights automagically generated in Clubhouse to help translate software development to business outcomes.

Codacy

A new tool on the block for us at CBG is a tool called Codacy. Codacy is proving itself due to its seamless integration into our workflow. In fact, our teams don’t even know it’s there until they try to commit sloppy code.

Integrated workflow

Typically, that sloppy code will be denied by Codacy during a pull request when it blocks it and gives you detailed feedback and actionable results on what needs to be cleaned up. It’s that automagic code review, and the trackable action item, on our team’s commits and pull requests that is the secret sauce for us.

When Codacy gives us those actionable results, it saves us time by providing a quick link to what caused the denial or the quality issue, how to fix it and even community maintained documentation to give more context when available.

We have found that our code quality is much simpler to maintain because we can simply block merges of pull requests that don’t meet our quality rules. We have a lot of flexibility and control of our standards and it’s a learning opportunity for our teams to customize those rulesets in order to remove false positives. It’s also a superb onboarding tool for new employees getting up to speed with our team’s high quality standards.

Inventory technical debt

We are able to embed code quality checking alongside our commit and pull request flows. During that process, Codacy builds an inventory of technical debt for more than 30 programming languages that technical leads can use to map out a payback roadmap.

We are able to prioritize technical debt that has been identified, and more often than not, when technical debt is identified during a pull request our team decides to tackle it and not let it become debt in the first place. We also can keep track of code coverage and identify exactly which lines of code are being covered by our test suites and which aren’t.

Simple quality & security scanning

In addition to the standards that our teams define, there are tons of out-of-the-box rules that you can apply immediately through Codacy’s UI and start learning how your code may be deviating from industry standards. It also includes in-depth security scanning for identifying vulnerabilities against OWASP Top 10. We have found that it has prevented critical issues from making it to production.

What won our teams over?

Providing actionable results, that gives our team clear direction on what to address, embedded right into a pull request conversation is what won me over on this tool. Our team embraces quality engineering so that we don’t have to staff for a separate quality team. All of our architects, engineers, and developers are expected to grow a quality engineering skillset. Codacy takes a little bit of that burden off and helps us keep our staff lean and mean.

Our favorite parts of Codacy are the questions that it helps our team’s answer.

• How is our code quality for our project?
• How much, if any, technical debt does our project have?
• What areas of code cause more problems than others?
• What is the overall health of our project and how has the quality evolved?

Codacy has found a first-class spot in our software development toolchain because of the work that it automates and removes for my teams, while helping us maintain high quality standards in our codebases

LinearB

LinearB is the newest member of these tools for my teams. Our teams are still determining the value level of this tool. On the surface, it’s outstanding due to it’s ability to provide development insights like no other tool I’ve encountered. The tool excels at automagically analyzing a team’s repositories, projects, and release data so that teams and leaders have access to real-time insights and metrics. From their own site:

LinearB analyzes your people, projects and code to help you translate engineering metrics to business results.

They call this “Software Delivery Intelligence.” We have found that the insights gained does indeed help our teams continuously reduce delivery times by making decisions based on the real-time generated insights . It’s also effective at providing visibility to the productivity of a team, and gives solid insights in to what each team members is focused on.

The tool has different value for different technology roles within an organization:

• For developers, engineers and technology leads, the tool excels at analyzing pull request frequencies, counts, reviews, merges, tagging, releases, and more to give a fairly individual view of what each technologist is up to. This picture looks vastly different than the project-focused view presented in Clubhouse or other project management tools.
• For CTOs & VPs of Engineering, they’ll find that they’re able to
  live between their two worlds more effectively in that they’ll be able to correlate development insights to real business outcomes.

It’s about the conversation, not the numbers

In my honest opinion, the real value in this tool isn’t necessarily the exact numbers the tool provides, but more in the conversations started with humble inquiry as to a team’s behaviors driving the context. Questions that our teams tackle in a safe environment are the following:

• Where are we investing?
• When are we delivering?
• How can we improve?
• Who needs help?

In addition the questions and conversations, the built-in Dashboard and extended features provide easy access to and simple tracking of modern team metrics like delivery efficiency, code quality, priority focus, team health, and PRs open and merged.

Using log data provided by a team’s git provider, it’s also simple to identify project blockers, shadow work, real-time project status, and significant project delays.

Another feature our team hasn’t tried yet is the configuration of targeted, real-time alerts and commands to enable process configuration, policy guardrails, task automation, and more personal insights (not necessarily tied to a team.)

How our team uses LinearB

Our team tends to focus on a few key pieces of functionality within LinearB. We definitely strive to continuously improve with team-based metrics by finding opportunities to improve delivery efficiency and quality. The insights and metrics help drive those conversations, and help us to broadcast intra-team trends and performance.

Not all of our team members feel the same way about retros, but I love a good retro. The moment our iterations are complete in Clubhouse, I can rest assured that a fresh retro report is available in LinearB providing insights that Clubhouse has no clue about. We’re starting to have some very concrete discussions with this highly insightful data available to the team.

We also use LinearB for identifying team burnout. It’s simple to see how many days team members have been active during an iteration, how much perceived work they’ve done, how much WIP someone has, and if they’re in trouble. At CBG, we strive to protect our team members health, and this tool helps in that regard.

We also use LinearB in stand-ups, though not every day. It seems to be about every other day that we pull up the report. We can easily see recently completed work, WIP, high-risk code and blocked PRs for each person on our team.

Some lessons we’ve learned

1. Firstly, dev execs and tech leaders using LinearB on their teams will need to put in extra effort to ensure culture doesn’t become a numbers-driven culture. Your team will feel threatened and will not feel safe to thrive.
2. The conversations started because of the numbers are the important factor here, not the actual numbers themselves. There’s always more to the numbers than what is at surface level. And like anything in software development, teams cannot and should not be compared against other teams for the sake of numbers.
3. LinearB needs to be used in conjunction with enforced and automated pre-commit standards, metrics, auto-linters. If there isn’t a consistent approach, team members start to feel like it’s a numbers game. If your team doesn’t have enforced standards, lint rules, development patterns, then don’t integrate LinearB until you do. Otherwise you’ll end up with committed code that is bloated to game the system.
4. Committed and generated artifacts need to be similar in purpose, format, and delivery in order for the numbers to mean anything for a given team. A real-world example is when our team had a large collection of auto-generated 1-line JSON files in a repo. One day we applied a prettifying pre-commit rule to more accurately track code changes in these JSON files. On that initial day of the new rule, our 1-line files turned in to prettified 1K-line JSON files, which artificially inflated productivity.

TL;DR

In summary, I try not to get to married to specific tools in my teams. Some of the best technology teams I’ve worked with had barely more than sticky notes, an internet connection, and a Chromebook with built-in editors to generate code. When I do stumble across tools that make technologist’s lives more simple, or that help correlate development insights and metrics to business outcomes, I want to embrace them and share them. These three tools fit that category. Hope you find some of the post helpful for you and your teams.