JIRA was originally developed as an issue tracking tool but is turning into a more complete agile project management tool. This also shown by the recent shift in Atlassian’s branding strategy for JIRA. Whereas JIRA was targeting mostly software development and IT teams, it is now presented as a generic collaborative tool. Practically any team (marketing, HR etc.) that wants to collaborate and track work, projects and requests effectively can set up JIRA and start working with it.
And indeed, JIRA has become a versatile tool with a long list of customisable features. To cater your process, JIRA lets you easily develop workflows and set permission of all sorts. Notification schemes make sure you get notified when you need to be. In order to save all the information that your team finds important, JIRA lets you configure multiple types of customfields. These customfields can be toggled on and off on different screens. They can be configured as required upon the creation of a new ticket. All this data can be visualised and reported on by configurable out of the box dashboards. Then there are the kanban- and scrum boards to support your agile way of working. They provide features for backlogs, sprints and versioning. The possibilities are virtually endless.
The complexity and its effect on team collaboration
With versatility comes complexity and all these configuration options and feature possibilities can quickly turn into a pitfall. JIRA administration often starts as someone’s side job and can lead to teams having to set up and configure projects for themselves. A lack of administration experience can lead to security risks due to wrongly configured permission schemes. Some JIRA instances contain thousands of customfields, often with numerous duplicates. The number of customfields implemented has a big impact on performance. Besides performance suffering, there is the inefficiency of having multiple different fields used to capture the same type of data. For example: one team uses a field called “departments” to be able to relate tickets to a department of the company, another uses a field called “units”to capture the exact same data. Master data is lacking. Workflows are another component that easily turn into inefficient bureaucratic processes, rather than being flexible and catering to a team. Processes should be treated as a first class citizen, but often project administrators tend overcomplicate a process when they design them in JIRA. When it comes to terminology of statuses, the same applies as with customfields, statuses often represent a similar state but different teams use different terminology. An example we see is “blocking” and “blocked”. The inconsistency makes reporting over multiple teams or organisations close to impossible.
JIRA provides all these tools to create highly customised solutions. Whilst for small and medium sized companies this might not be too much of a problem, as “John the JIRA guy” manages to keep everything together, in an enterprise environment this is very different. In an enterprise environment this results in unstructured instances that become increasingly difficult to maintain. In order to functionally scale JIRA on an enterprise level, the right amount of standardisation and governance needs to be in place. At Devoteam we approach JIRA solutions in a structured way.
Coming soon: Clean up or set up JIRA from scratch
In part 2 of this JIRA series, we will go through steps and best practices that can help you clean up your JIRA, or set it up correctly from scratch. In part 3 we will discuss a client case where we migrated multiple instances of JIRA to create a greenfield JIRA instance that functions as an enterprise wide single source of truth.
Follow us and stay updated about the latest blogs
 |
 |
