Managing Atlassian tools is not just about meeting the needs of your teams, but also about maintaining the health of your instance. Defining management and configuration policies is a key part of management that is often overlooked. In this publication I try to present what are some of the key criteria when defining them and what is the impact that they can have on the scalability of the solutions. From my perspective those are the following
Custom Fields Creation
Creating custom fields is needed in order to manage the project activities correctly. However, not establishing clear guidelines of what types of field should prevail over others as well as the characteristics that their names should have can lead to the number of fields growing exponentially over time. Even things as simple as putting a default value in a field can make future tasks difficult. I have seen on multiple occasions this configuration applied to global contexts of the fields, meaning that absolutely all the tickets of all the projects had a value in that field, making the task of cleaning out of use fields practically impossible.
To see other important points to define in the custom fields you can review our previous article.
Screens and Workflows Customization
Although it might seem that these policies could be independent of the custom fields creation policies under a first impression, we realize that this is not the case when we look in more detail. Hand in hand with the creation of fields, come the requests to display them in different parts of the process and under certain conditions.
This can clearly translate into more complex workflows that are less likely to be reusable in the future in other projects.
Among some things to highlight we can mention the following.
Statuses with generic names: It is more common than one would like to see workflows with statuses such as pending approval or pending response when for all practical purposes they are all the same in terms of metrics and conditions. These just make the workflow more complex and minimize the chances of reuse.
Unique transitions: Establish that the transitions to the same status are always the same and therefore with the same fields to be displayed on the screens, regardless of the ticket's original status. I must be able to count on the fingers of my hands the number of cases where the client has been able to justify to me why, coming from different status, the information requested should be different. Although in a first instance it does not seem to have a major impact, at the time of troubleshooting, these are more potential points of failure to review and correct or simply to add new conditions to the process.
Simple processes or with high reuse: Perhaps one cannot at the administrator level justify that the processes are simple but it should be part of the negotiation arguments so that the processes do not escalate in complexity and can be reused by other projects in other areas. As this is not always the case, it has happened to me on several occasions having to customize processes knowing that the same would have a high reuse level in multiple projects of the instance to avoid that the working hours to meet the demand of all teams do not scale exponentially.
Projects Archival and Deletion
Retaining projects forever and ever is not a good strategy for administrators, as it makes it practically impossible to correct past mistakes. We can end up with disused fields that cannot be deleted or statuses that are not aligned to the standards and then it is more difficult to justify them when an end user comes to ask for one that does not comply with the standard.
As a result of this it is advisable to establish an inactivity time of the projects and then proceed to archive them and a subsequent deletion of the same within what allows the company's policies as such. It is possible that certain projects may not have to be deleted for five or ten years due to record keeping needs, but not all of them must necessarily comply with this standard and it opens up the possibility of keeping only what is indispensable and therefore as organized and orderly as possible.
Configuration Items Naming Convention
Standardizing names is essential to maintain consistency throughout the product configuration. In many cases when there is a single administrator this may not seem to make much sense, but one must take into consideration that eventually one as an administrator may leave the position or a couple will join in to help with the administration and there is a chance that consistency will be lost and therefore product management will be more difficult. When everyone names the configurable items in their own way, then there is only one understands what they mean and the potential impact they can have if someone else modifies them.
Changes Approval
As a result of Jira's best management practices, it is important to reuse configurable items. This means that potentially every change requested by a user has an impact on a larger number of projects as the instance as such grows.
That is why, hand in hand with the reuse of configurations, there must be a defined policy on who should approve changes that have an impact on multiple projects. Clearly, consideration should also be given to what happens if the requirement is critical but not approved by the respective approvers. In many cases these may be indicators of a bifurcation in the configuration of the projects, which must be worked with subtlety to avoid that each request becomes a new bifurcation, thus moving away from the good practice of configuration reuse as mentioned above.
Adding Apps to the Product
Similar to the previous point, where changes to a workflow could have a massive impact at the instance level, adding an extra application is another case where the impact is not only across the entire platform but can have an economic impact and additional effort for the group of platform administrators. In these cases it is more difficult to have a single approver as in previous cases, so the policy should consider different factors that help define which products will be incorporated into the solution. Among the most important things to consider would be the cost of the product, the number of users or projects that require it and would make use of it, the number of functionalities available where potentially one application could satisfy what in other cases should be done with two or more applications.
Although this document talks about policies, it is likely that in some cases, more than policies, they end up being recommendations and guidelines where to a certain extent there has to be flexibility in one or more of the mentioned items. Clearly, the less flexibility that needs to be applied, the easier it will be to manage and maintain the products. Do not forget to document all these policies in Confluence or some other platform where the information is available and public so that all users can see it.
Do you have a different criteria to implement what is presented? Tell us in the comments
It is very common that there is more than one way to do things with Atlassian tools and we would love to discover other ways to solve them.
We hope you enjoyed reading,
Until next time.