minware Engineering Analytics Adoption Plan Template

The following is a template you can use to create an adoption plan for rolling out engineering analytics in your organization.

This template is one part of the adoption process. Please see the full Engineering Analytics Adoption Guide for more information.

This template covers most of the questions that typically come up during the adoption process, and is geared toward organizations that are fully rolling out minware to their whole engineering organization.

If you’d like, we are happy to walk through questions about your organization on a brief call and customize this plan for you, or adapt it more extensively if it doesn’t match your use case, just let us know!

---

Overview

As we grow, it is important to mature our processes and continually improve our engineering capabilities. We need to get better at meeting our commitments and predictably delivering value to our customers. These goals are crucial for the business, but will also improve developer experience and enable everyone to have a greater impact.

We will provide the engineering team access to minware to help quantify, focus, and target continuous improvements to how we work. This is a tool aimed at helping us get good at the fundamentals of effective software delivery for our current size, and it will set us up to further grow without slowing down.

General Questions

What is minware?

minware is an engineering analytics platform designed to monitor and improve various aspects of our software development process health, ranging from source control and ticketing to sprint effectiveness and technical debt management. minware’s Scorecard provides a detailed breakdown of areas that need improvement, with information about specific branches, tickets, sprints, and projects.

Why are we implementing minware?

minware’s scorecard will help us standardize our processes, run more effective sprints, and deliver software more predictably with high quality. Software is the backbone of our organization. This effort will help us build it more easily, and make the process smoother for everyone.

In particular, the scorecard will help us in these areas:

• Consistent Use of Source Control - We aim for uniformity in how we use Git. Having consistent expectations will make life easier for authors and reviewers, and decrease the risk of quality problems.

• Effective Sprints - Our goal is to maximize the value we deliver each sprint. To do this, we will need to identify the root cause of issues that interfere with delivery during our retrospectives and address those issues.

• Predictable and Rapid Software Delivery - We aim to enhance our speed while maintaining predictability and quality. The scorecard will help us do this by decreasing interruptions that get in the way.

Focused Continuous Improvement - We need to constantly improve, and the scorecard gives us a common language for focusing on the improvements that will have the biggest impact.

While improving the way we work is critical, it's only a piece of the larger puzzle. We need to improve in a number of other areas too. Getting these basics right is necessary (but not sufficient) for our overall success.

The scorecard is one tool among many that we have which facilitates the right coaching conversations around team/individual performance, succession planning, and workload allocation. It does not reduce engineering effectiveness to a single number but provides a basis for conversation about where we can improve.

When are we implementing minware?

All engineers will gain access to this minware starting on [date]. After that, teams should review the scorecard data collectively once per sprint.

Where do I go for information about minware?

You can read the Walkthrough Documentation for information about how to use each report.

How will we roll out minware?

minware will be made available for all teams at once. To ensure everyone understands how to interpret and act upon the data:

• A demo/Q&A session will be held with minware.
• We will have an internal Q&A session to discuss any questions about how we will use minware.
• Recordings will be made available of these meetings.
• Managers will discuss minware during the next one-on-ones following the implementation.

Usage and Access

Who will have access to minware data?

All engineering team members will have access to their own data[, the data of their immediate team members,] and summary-level data for other teams and the entire organization.

Managers and engineering leaders will be able to view [all data].

[Others outside the engineering team will be able to view summary-level data for teams, but not individual data.]

How often should we review the scorecard?

The scorecard is meant to be reviewed by members of a Scrum team during the sprint retrospective to identify opportunities for improvement.

Are there any restricted sections of minware?

No, apart from administrative functions, there are no restricted sections aside from account administration pages. However, within the reports, individual and team data that people do not have permission to access will be hidden.

Where does the data in minware come from?

The data for minware is derived from commit and pull request activity [GitHub], and ticket/project activity in [Jira].

Performance Management and minware Metrics

Will the scorecard be used to compare teams or individuals?

No, the scorecard is not intended to rank or compare team members or teams against each other. Its primary purpose is to help individuals and teams improve over time and to align team activities with organizational objectives.

Will we establish across the board standards such as a number of commits or pull requests which define acceptable performance by an individual?

No. Even though you may have read about Uber doing this, we believe it is a naive view of engineering performance. However, you and your manager may set individual targets using the scorecard metrics based on your role.

How will the engineering scorecard be used in individual performance reviews?

The scorecard serves as one of several tools in our performance management process. It offers objective metrics that guide discussions about strengths and areas for improvement during one-on-one meetings with your manager. The goal is not punitive action but to identify pathways for individual growth and development.

Should I still try to optimize scorecard metrics if it seems like doing so will have a negative impact?

You should talk to your manager if you find yourself in this situation. In short, processes are designed to handle the common case well, but might lead to bad outcomes under unusual or unanticipated circumstances. Also, fretting about being perfect 100% of the time may not be worthwhile. So, not trying to optimize metrics may make sense some of the time, which is why a lot of the passing targets for the scorecard are 95% and not 100%.

That being said, while overriding a process might lead to better results in a specific situation, it can lead to a worse global outcome over time. This can happen by eroding trust in the predictability of workflows across teams, or by preventing leaders from having the visibility they need to make better strategic decisions. So, it is important to discuss this broader context with your manager in this situation.

Is the scorecard the only tool used to evaluate performance?

No, the scorecard is just one aspect of a broader performance evaluation framework, which may include [peer reviews, self-assessments,] manager assessments, and other forms of qualitative feedback.

How often will the scorecard data be reviewed in the context of performance?

The scorecard metrics are meant to be reviewed at least once per sprint as part of the team's regular activities. However, they will also be part of the ongoing performance discussions that happen in your one-on-one meetings with your manager.

Will the scorecard affect promotions, raises, or other employment decisions?

The scorecard can contribute to such decisions but only as a part of a multi-faceted evaluation process. It can identify areas of strength or necessary improvement, which might be considered in the broader context of career development and growth.

Can the scorecard be used to set individual performance goals?

Absolutely. The scorecard is an excellent tool for setting specific, measurable, achievable, relevant, and time-bound (SMART) goals. For example, if one of the metrics reveals an area for improvement, you and your manager can set a SMART goal to address it.

What should I do if I have concerns about how the scorecard metrics reflect my performance?

If you have concerns about how the scorecard is representing your work, it's essential to discuss these issues openly with your manager during your one-on-one meetings. The aim is to ensure that the scorecard is a constructive tool for everyone.

Organizational Goals Related to the Engineering Metrics

What are the near-term organizational goals for the engineering scorecard?

By the end of [Q4], we aim to achieve passing scores at the organizational level for two main categories: ["Version Control Hygiene" and "Ticketing."]

[While the later metrics are important as well, the first two categories will be our immediate focus, and we are likely to set goals for other metrics in subsequent quarters.]

I’m not sure how to improve a metric, where do I go for help?

You can first look at the documentation in the scorecard report by hovering over the help icon, which provides a general explanation of how the metric is calculated and how to make it pass.

If you have deeper questions about things like how to split a complex task up into smaller pull requests, talk to your manager or a senior team member for advice about what to do.

I’m assigned a ticket that has an issue but was written by someone else, what do I do?

This may happen with particular metrics like use of epics, or estimates for tickets where someone else has more knowledge about the task. You should reach out to the person who wrote the ticket and ask them how to fix it, then apply the fix. If this happens repeatedly, let your manager know. You should not fill in values that you’re unsure of just to make the scorecard metrics pass, which would be counterproductive.

Why are we focusing on [Version Control Hygiene and Ticketing] metrics?

These [two] areas are foundational for effective and efficient software development. Achieving consistency in [Version Control and Ticketing] will improve our development process and contribute to the broader organizational goals.

What is the timeline for these organizational goals?

We aim to reach these organizational goals by the end of [Q4].

How will these organizational goals be measured?

Achievement will be measured by attaining passing scores in the specified engineering scorecard categories. We'll also collect qualitative feedback through sprint retrospectives and one-on-one meetings to assess our team's understanding and implementation of best practices.

What is the action plan to achieve these organizational goals?

The plan involves an initial assessment, specialized training and resources, check-ins by managers during each one-on-one meeting, and ongoing reviews during sprint retrospectives and one-on-one meetings. The plan will be adjusted based on our progress and feedback.

Are individuals accountable for these organizational goals?

Yes, all team members contribute to these organizational goals. Progress will be regularly reviewed by engineering leadership[ and reported to the CEO].

How do these organizational goals align with individual performance?

While these are organizational goals, progress toward them will be a part of individual performance discussions. Successfully contributing to these objectives can be a positive indicator in performance reviews.

Miscellaneous

Who should we reach out to if we have more questions?

For more in-depth questions or clarifications, consult minware’s documentation, or reach out to your manager, who may contact support@minware.com for technical questions.