Jira Architecture for Agile Operations

FollowingFollow

Connecting processes, people and technology to amaze my wife with a beautiful Diesel Wallet Bag.

Quick Overview

This section will be a review for experienced Jira users.

Everything in Jira revolves around Projects, either as Service Management Projects or Software Projects. These might be better named "containers", where you configure your processes and related structures. One major difference between the two is that a "Service Management Project” is ideally used for Operations Management, making the "project" term misaligned to the current purpose.

Another key concept in Jira is the Issue. This reflects Jira's origins as an issue tracking tool, but Atlassian has since built many powerful capabilities beyond their original purpose. A better term today might be "Process Type”.

Thus we could say that each Jira Container (project) supports a schema of processes (issue types) linked to a workflow. For example, a Jira Service Management container could support two processes - Service Request and Incident - with each type linked to their respective workflows.

Each of these elements may be connected in different ways. For example, the same issue type may connect with a single workflow or potentially different workflows in another project. Jira customizations even enable multiple teams to use the same "Bug” process (Issue Type) with slightly different workflows tailored to the needs of each team - which might not necessarily be good in terms of efficiency, ok?

Refer to the example in the diagram below where both projects use the process "Bug” (Issue Type) with different workflows. This flexibility allows us to track all bugs across teams, but without necessarily obligating them to follow the same exact process.

This flexible structure of Projects, Issues and Workflows makes Jira great, but brings potential pitfalls at the same time. Without a proper knowledge of management practices (e.g., Scrum, Kanban, BPM, Service Management, etc.) it is easy to build up poor, inefficient, and frAgile Jira architectures.

It’s common to see companies with dozens of different workflows that are almost identical, with minor differences. Often these could be integrated into a single workflow, benefitting from standardization. Another common scenario is teams using a Service Management project with a Kanban board, which doesn’t make sense at all as we will illustrate later in this article.

Operations x Projects

Jira's evolution as a Service Management tool has raised some challenges for management professionals. Most are related to the lack of integrated knowledge over the differences between managing Projects and Operations. This knowledge gap combined with Jira’s flexibility can be a recipe for disaster for process excellence.

The first step towards getting this right is understanding that operations and projects are different problem domains with complementary logic, objectives and processes.

For example, in Agile project management, you might benefit from a sprint-oriented workflow. Yet this approach is not applicable in an operational context: what business would be willing to wait for a sprint to accomplish an access requisition?

On the other hand, it wouldn’t make sense to set standard Service Level Objectives (SLO) for the delivery of a product. Agile project management is frequently open to dynamic priority changes based on market dynamics and strategy adjustments.

This is not the focus of this article, but bear in mind that, sooner or later, you will stumble upon conceptual pitfalls if you are not using the proper tool or practice to achieve a given objective.

Challenges

In 2018, after a careful analysis of the top Service Management tools in the market, we decided to give Jira a chance to be our Service Management tool.

Surprisingly, we ended up discovering that with the proper architecture, Jira could accomplish almost all the requirements we had for a Service Management tool. We could also avoid many integration problems in case we decided to replace it.

The next challenge was to find a structure for Jira Service Management that enabled fluid process flow in F-Tech Engineering and F-Tech Operations. Adapting it to the team’s Agile modus operandi involved the following considerations:

As small an impact as possible on the lean initiatives’ roadmap;
Ensuring a fluent interaction between operations and projects;
Shielding the customer from technical language, and shielding engineers from small interruptions that could be handled by support teams;
Quickly finding the proper team to resolve incidents and reduce the time to recover; and
Preventing issues from getting lost among development teams without proper accountability etc.

From a technical perspective, Jira might bring challenges, such as:

The Service Management Portal needs some improvements yet;
Many things depend on acquiring additional add-ons;
Missing features for advanced SLA configuration, such as those based on attributes;
The permission structure needs some improvements in terms of giving teams more freedom without making them Jira Admins;
The Service Catalog structure doesn't support multiple perspectives, such as customer-oriented or technology-oriented, nor does it allow us to control customer access to specific items; and
Queues feature focused on small teams, not built for scaling.

Jira Service Management Architecture

Despite Jira’s improvement opportunities, you may achieve the objective without incurring a cost increase. However, it will require creativity and combining technologies in a smart architecture, informed by a deeper knowledge of IT Service Management and Agile practices.

Below you will find a generic representation of the F-Tech Service Desk architecture:

Multiple service desks were set up with shared standard configurations whenever possible. Custom settings were used whenever necessary, such as fields, a service catalog, specific automations and Service Level Objectives.

Let’s review the main challenges with the proposed solution.

Service Catalog

Jira’s Service Catalog is configured through "Request Types”. Do not confuse these with Issue Types. However, there are only two levels for configuration: for individual request types and their groups.

It may be enough for a small company, but it becomes a challenge once this starts to scale.

To resolve this problem and enrich the Service Catalog, we created multiple service management projects with the same category. It allowed us to gain an additional level for grouping Request Types in the Service Catalog. It also provided more modular management over the multiple service lines and related customers, the ability to control specific accesses, greater personalization of the customer experience and greater overall flexibility despite its standardization.

Queues

The Queues feature in Jira is limited to only its related project. Hence when supporting multiple Service Desks, a new challenge arises: how to manage queues? And the answer is simple: instead of using Queues, use "Dashboards” and the "Filter View” gadget.

Jira Dashboards worked really well for us despite being almost useless for most reports and lacking good usability.

By categorizing all the standard projects, we’ve made it more scalable and it can be easily shared among different teams. When adding a new Service Management Project, all teams start seeing it automatically with no further side-effects.

That scalability is strategically important because FARFETCH’s dynamic and Agile environment demands quick responses for changes in strategy and direction, such as team reorganizations.

Services Portal

Jira Service Desk Portal is also limited in terms of features usability and flexibility. Beyond some minor features, you cannot personalize it or make advanced configurations to improve the customer experience. So we decided to make our own front-end using our intranet tool, which could be created by anyone using something as simple as a Google Sites static links or Google Scripts to call the Jira Rest API and build the catalog dynamically.

However, with this new modular structure, thanks to using multiple Service Management Projects, we were able to personalize it for our customers. We achieved this not through Jira’s out-of-the-box customization features, but instead through a smart architecture which allows us to hide or show different Service Catalogs set up through different Service Desks.

Knowledge Base

As we have multiple teams under different management structures, offering a standard service that guarantees a consistent satisfaction level could be difficult. However, using Confluence with Jira showed promising.

All Service Management Projects are connected to the same Knowledge Base, which uses the same templates and standard article types such as Troubleshooting and How-Tos. This allows information to flow through all teams in a dynamic manner, since each agent is continuously feeding this base that serves all teams. Our knowledge base is maintained, updated and improved by each individual, making the whole process more consistent, resilient and the customer experience much more comfortable.

Besides that, all the Postmortem Documents and Incident Reports are maintained in that same Confluence space. This supports our core value of transparency, making them available to the Service Management team whenever a new incident is registered and to our internal customers whenever they search the Portal. This way we keep our lessons learned updated, we can monitor the recurrence of major incidents, and we can make our relevant organizational knowledge more available within the natural flow of the support process.

Process Architecture

A proper Process Architecture allows us to transform Jira’s weaknesses into strengths, Meanwhile, some of Jira's strengths provide us with useful capabilities:

Flexibility

I’d classify Jira as a Process Orchestration tool. Its structure of Project (containers), Issue Types (Process Type) and Workflows allow us to implement whatever process we want, from SCRUM to Incident Management, and connect them.

Connectability

Jira could be used end-to-end, from strategy and governance, passing through projects and operations, and everything can be linked. This makes it possible to have an integrated view of the tickets registered to resolve an incident, for example.

Process Integration

If your company has a "value chain”, or a macro process end-to-end where all of your processes are connected, you could use Jira to track the whole service life cycle very easily.

Complexity Abstraction

You may use the issue type "Bug” in all the projects, but each project could have completely different workflows. This reduces the complexity of the organizational structure, as any user would know to always create a bug and that it will be resolved, regardless of how.

However, you’ll only be able to get the most from your technology if you master the management practices and build a smart Process Architecture. The reverse is also true: you’ll only be able to implement management practices with a set of good process orchestration technologies.

Although we won't deep dive into process architecture, here are some key aspects you should take into consideration:

Everything in operations starts with a Service Request or an Incident, the only two issue types available through the Service Catalog;
Remaining processes are triggered by these two types, such as Problem, Change etc.;
The Global Service Desk structure is a central contact point for interaction between areas;
We can’t interfere too much in the team’s development processes.

Results

With this architecture of processes and Jira in place, all teams could be both customers or suppliers of these "corporate services”. Here are some of the potential outcomes:

Incidents are resolved much faster;
KPIs for the process are trackable end-to-end, which is only possible due to a standard and coherent structure;
Service Requests can be now executed by less experienced people because there are documented, standardized processes that make it easy to connect tickets and the knowledge base;
It’s possible to have multiple teams from different management structures working together on the same platform;
Different teams all across the globe can quickly escalate issues to each other without dealing with the complexity of understanding who, where, how, etc.
Improved collaboration across teams;
New teams can onboard faster and more easily;
Compliance is assured and reported efficiently due to a standard structure;
Potential compliance issues are easier to address between teams through the single contact point;
The central structure acts as an effective governance control point;
Development team sprints are less impacted by operational errors while the Global Service Desk teams implement workarounds supporting customer continuity;
Issues escalated to development teams enter their usual board workflow regardless of source;
Major Incidents are quickly addressed by a central point of contact that has all the communication cards mapped and available.

And it doesn’t stop there! As Jira has a set of issue/process types with different workflows that may be connected with each other, the benefits go even further. Because all objects used in a Service Management Project can connect to Software Projects, we don't need to standardize everything to be able to track it across teams. We can just create a bug for any team and know that it will be resolved.

This is a good balance between agility (flexibility, empowerment and autonomy) and operations (standardization and efficiency).

Conclusion

Despite all the improvements still necessary, Jira is a flexible tool which allows us to do great things for a better cost, since it’s built over a best-practices-based process architecture.

F-Tech teams can be creative while still able to reduce costs and increase process efficiency.

Don’t forget to share this article with your friends!