Sole Survivor: How Fidelity Investments reduced Jira customizations by 99% | Team '23 | Atlassian

Summary

The speaker from Fidelity shares their journey of consolidating a sprawling Jira instance with thousands of projects and customizations. They detail the process of reducing workflow statuses from 1418 to 12 and custom fields from 2008 to under 100, enhancing performance and usability. The talk covers strategies for managing pushback, leveraging tools like Project Track and Script Runner, and the importance of templates and archiving old projects. It concludes with the satisfaction of a cleaner, more efficient system and the positive feedback from initially resistant users.

Takeaways

• 🕒 The speaker recounts the transition from using multiple tools like RTC, Rally, and Jira to a standardized enterprise instance of Jira in 2009.
• 🔧 There was a significant issue with over-customization in Jira, leading to performance issues and inconsistencies in how teams worked.
• 📊 The company had an extensive list of custom fields and workflow statuses, which were reduced for better standardization and performance.
• 👥 The process involved consolidating numerous Jira administrators into a smaller, more knowledgeable team to manage the enterprise instance effectively.
• 🛠️ The importance of balancing team autonomy with enterprise control was emphasized to ensure consistent processes and standards.
• 🔍 The reduction in custom fields and workflow statuses improved reporting, analytics, and administration, making the system more manageable.
• 🔗 The need for integration with other tools like Jira Align and custom tools was a driving factor for streamlining Jira's configuration.
• 📉 The company faced pushback from teams resistant to change, but eventually, these teams acknowledged the benefits of the streamlined process.
• 📝 The script discusses strategies for reducing custom fields, such as analyzing usage, consolidating similar fields, and removing unused or cloned fields.
• 📉 The company successfully reduced the number of workflow statuses, custom fields, screens, and issue types to create a more streamlined and efficient system.
• 🌐 The push towards cloud migration was another reason to declutter the Jira instance, aiming to avoid carrying unnecessary legacy configurations into the new environment.

Q & A

What was the primary reason for adopting Jira at Fidelity in 2009?

In 2009, Fidelity needed a tool to manage work in a consistent way across the organization as various teams were using different tools like Rally and Jira. Jira quickly became the preferred choice due to its flexibility and the need for an enterprise instance that everyone could use in a similar manner.

Why did Fidelity end up with numerous Jira Administrators and extensive customizations?

Fidelity had a lot of people wanting to use Jira, but with a very small team to manage it. This led to the creation of many Jira Administrators across the enterprise who didn't have all the necessary knowledge, resulting in extensive and inconsistent customizations.

How did the overuse of custom fields impact the company's reporting and data consistency?

The overuse of custom fields, with some being misspelled and others capturing the same data in different formats, made it difficult to report on data or maintain a consistent process across the company, as people were using different fields for the same data.

What were the main reasons for standardizing Jira at Fidelity?

Standardizing Jira was important for improving performance, simplifying reporting and analytics, easing administration, enabling easier integration with other tools, ensuring a consistent process for associates, and enhancing usability by reducing the overwhelming number of fields on screens.

How did Fidelity reduce the number of custom fields from 2008 to under 100?

Fidelity started by identifying and removing fields with low usage, similar names, and fields that were no longer on any screens. They also addressed fields with the same value and those that were cloned unnecessarily. The process involved analysis, engagement with power users and admins, and the use of tools like Script Runner.

What was the strategy for consolidating the 1418 workflow statuses into a more manageable number?

Fidelity streamlined the workflow statuses by standardizing the core statuses and allowing individual projects to select additional statuses they needed. This was achieved with the help of an app called Project Track, which enabled project-level configurations that could influence workflow conditions.

How did Fidelity address the issue of having 3685 screens reduced to 154?

The reduction in screens was part of the ongoing effort to tidy up and standardize the Jira instance. While the script does not provide specific details on this reduction, it implies that a thorough review and consolidation of screens were conducted to ensure they were necessary and not duplicates or obsolete.

What was the initial resistance Fidelity faced when trying to standardize Jira, and how was it overcome?

Initially, there was pushback from teams who felt that standardization would stifle their unique processes and needs. However, after the standardization was implemented and its benefits became apparent, such as improved performance and easier workflows, the previously resistant teams acknowledged the improvements and admitted that the changes were necessary.

How did Fidelity ensure that the standardization process was well-communicated and understood by all stakeholders?

Fidelity used various methods to communicate the changes, including engaging with power users and admins, creating generic fields for miscellaneous data, adding banners on Jira to direct users to a Confluence page with detailed documentation, and renaming or disabling fields that were being decommissioned.

What lessons did Fidelity learn during their Jira standardization journey?

Fidelity learned the importance of starting with low-hanging fruit, limiting the number of Jira admins, putting guard rails in place to prevent new customizations, creating templates for new projects, archiving old projects, and using listeners to clear custom fields on cloning. They also discovered the satisfaction in deleting unnecessary configurations and the value of using apps like Project Track, Script Runner, and JXL.