Tech Group work processes in Jira - how we implemented a software development tool in an industrial engineering company
In the first part of the Tech Group case study series, we learned why the industrial engineering company was looking for a new tool to support its work processes and how the Jira implementation process was carried out in an agile way.
In the following, we publish the technical background of the implementation.
Jürgen Talik, Atlassian team leader and Jira specialist, who played a leading role in the implementation process, comments on the technical details.
Additionally, Tech Group department heads share their thoughts on solutions.
Several departments and closely related work processes - how we created the basic structure
A Jira project is a collection of issues, where an issue indicates the work to be done.
In Tech Group, the company's different departments and related tasks are considered as a whole, so the processes are managed in one Jira project.
By default, there is a 3-level issue hierarchy in Jira, with Epic issue type at the top.
Epic typically represents a milestone - a large piece of work aggregating smaller tasks - standard (for example, Story, Task) and sub-type (Sub Task) issue types.
Illustration 1. Jira 3-level issue hierarchy.
In Tech Group Jira, all three issue levels are used, where Epic typically represents one machine order but can also represent a series of machines or some part of one order (for example, if machines are delivered in batches) - thus, it became possible to monitor the big picture, but also the related smaller stages.
"All work related to one machine order is under an Epic - standard issue types are used to describe department-specific activities," explained Atlassian team leader Jürgen Talik.
A total of 17 new issue types were created, representing the main processes - among others, for example, Sales, Design, Purchase, Picking, Production, Testing, Packing, Logistics, etc.
"In industrial engineering, it is not impossible that extraordinary surprises and problems can occur, which is why we created separate issue types to register and monitor them," said Jürgen.
"Sometimes the problem is related to a specific department-based activity, but it can also arise with entire or several orders," explained Jürgen.
In Jira issue type hierarchy, a sub-task issue type cannot be created directly under Epic, so problems had to be made both as standard and sub-task issue types to enable flexible management.
As for workflows, they vary quite a bit from department to department.
"Some are little more complicated, where transitions between statuses are limited, but in general, there was no need to limit workflows too strictly," commented Jürgen on the workflows.
Jira issue fields allow to add specific information related to a task.
"A lot of new custom fields were created over time, and a lot of them are related to machine orders - for example, there are deadline fields for different stages, order designations, fields for responsible persons etc.," said Jürgen.
Adding fields to screens can be done relatively quickly, but from the end user's perspective, it's commendable to use a standardized field sequence, especially if there are a lot of fields on the screens.
"I emphasized that the order of the fields on the screens was as similar as possible throughout. I grouped similar fields into tabs to avoid overabundance of information in one view. In this way, the user can navigate between the fields as intuitively as possible," explained Jürgen.
In our previous blog post, you can read more about good practices for managing and configuring Jira.
Kanban boards - aggregated view and department-specific views
Jira's agile boards visualize tickets as cards and allow you to move tickets between workflow statuses.
There are 12 boards in Tech Group Jira - 1 overview board that displays all orders (Epic tickets) and department-specific boards.
"The goal was that you wouldn't have to switch between different boards in addition to everyday work. For example, there is a separate board for problem issue types. Still, if the problem is addressed to an employee of the design department, this ticket is also displayed on the board of the design department," explained Jürgen.
This logic applies to all departments - a problem issue moves between boards according to which department employee it is assigned to.
Jira boards come with several user-friendly functionalities that facilitate ticket visualization and filtering.
It is worth using quick filters to quickly find the crucial issues among all issues displayed on the board. On Tech Group boards, quick filters are used to find:
- issues addressed to a specific person;
- issues related to a particular customer;
- certain issue types if several different issue types are used in the department.
Considering that the boards are used daily, it was essential to emphasize the visual user experience.
"In order for users to quickly find the necessary information, colour solutions are used on the issue cards. Each customer is assigned their own colour and priority and deadline fields are represented on the cards," said Jürgen.
Illustration 2. Production department's Kanban board.
Everything essential on one dashboard
A Jira dashboard displays information through gadgets that visualize the results of filters according to the gadget type.
"We created dashboard views for both department and team leads, and the principle was that everyone could see the topics they were interested in," revealed Jürgen.
"For example, the production manager needs an up-to-date overview of the machines to be delivered next. We created a filter for all the machines in progress and added it to the dashboard. The list of the machines is ordered by delivery date," explained Jürgen.
The goal was to collect the most important information in one view for every manager.
"Problem issue types addressed to the employees of his/her department are displayed on managers' dashboard, where both the assignee and the status of an issue can be seen," Jürgen added.
Illustration 3. ”Filter results” gadget.
During the implementation, it became clear that moving the complaints management to Jira was more reasonable instead of the previous Excel sheet solution.
"If the manufacturer of a component has sent a faulty item, a complaint to the supplier can be issued from a problem ticket," explained Jürgen.
The Xporter application is used to process complaints.
The application allows the information in the ticket to be exported to the desired file formats according to predefined templates - using the Tech Group example, a Microsoft Word document with a predefined structure is formatted.
Since one of the main reasons for implementing Jira was to reduce the number of emails, Jira email notifications were turned off system-wide.
Other notifications - for example, when a user is @mentioned in the issue's comment - can be followed under Jira notifications (bell icon in the top navigation bar).
"Unfortunately, the notifications under the bell icon cannot be configured. When actively editing issues in Jira, a situation may arise where excessive information clutter accumulates under the notifications’ section," Jürgen acknowledged.
Fortunately, tickets with a user @mentioned in the comments can also be obtained from Jira's issue search. The query can be saved as a filter, and the results displayed on a dashboard if necessary.
Jira automation and Scriptrunner
Developing automations was one of the most time-consuming stages of Tech Group's Jira implementation.
The goal was to reduce repetitive activities, and there were plenty of them – 45 according to the number of automation rules.
For example, an automation enabling automatic issue creation for another department is widely used.
“However, creating an issue is the user's choice - when they change the issue status, a screen appears, giving the user a choice of whether they want to trigger automation. If so, the automation creates a new ticket for the other department, linking both issues," Jürgen explained.
Among other scenarios, this kind of automation is applied to machine orders; when production moves an Epic to "Ready for Deliver" status, there is an option to automatically create a ticket for the quality department to output a customer satisfaction survey.
Illustration 4. Automation rule. The production manager wants to keep up with any issues related to the production issue that is currently in progress. Automation automatically links the problem-type issue created under Epic with the production ticket, so that the production manager has access to the information immediately.
Some automations synchronize the information in the fields between the sub-tasks and parent issues.
"For example, if a certain deadline is changed on an Epic issue, the automation will also apply the changes to the sub-tasks, but only if the date in the sub-task has not been changed beforehand," said Jürgen.
For quite a while, Jira's built-in automation, which automatically created issues and copied information, was sufficient.
Over time, however, new fields were added to the system and automation rules had to take these into account.
“This meant that many automation rules had to be manually reviewed after creating a new field to keep the rules up-to-date. The situation created not only an excessive administrative burden but also the risk that something would be overlooked," stated Jürgen.
It was decided to test the Scriptrunner plugin to improve the situation, which turned out to be a valuable solution.
"Scriptrunner uses the API to check all the fields on the create screen of the issue (except those you don't want to copy from the trigger ticket). If the information has been entered in those fields on the trigger issue, the automation copies everything necessary," Jürgen explained Scriptunner's efficiency.
Thoughts from Customer - what has changed compared to previous solutions and tools?
"It was a pleasant surprise how quickly we dealt with problems and improvements after going live.
In addition, I was initially skeptical of how much this software would help me, but in fact, Jira is beneficial for grasping the big picture. All the project information is in one place - from one issue, you can move to other department's issues and keep up with the actual status," commented Jaanus Paltser, Tech Group production manager.
"As for team leaders, we were basically able to give up emails, and in addition, all information about the project's problems is in one place and it can easily be used for the preparation of the next machines," added the production manager, whose department includes nearly 80 people.
"In the past, information about new projects came via email, which I entered in Trello, and we monitored the status in Trello. But now we completely abandoned Trello, and there are significantly fewer emails," said Ivar Kukk, Tech Group purchasing manager.
"Initial information is better, and the tasks are specifically aimed at someone; there is no question of who should act as with tasks sent by email, several people are included in one thread," added Ivar.
"It's also positive that all information related to an Epic is also transferred to sub-tasks, so there is no need to search through hundreds of emails to understand where the problem or task started. It's also very good that you can't forget anything, because all the tasks assigned to you are always in front of your eyes in the form of different filters," explained the purchasing manager.
"Information moves faster. Since client managers manage many projects simultaneously, all at different stages, their dashboard has been the biggest win-win. You get an overview of all projects at once," says Marko Mets, Tech Group's key account manager and customer management team leader.
"It's nice to see that there are endless possibilities to create different automations and implement business requirements in Jira. This capability makes process management easier. We can continuously improve this area," said Mari-Elts Vesiallik, Tech Group's quality manager.
… and what would the managers recommend to other companies looking for software to support work processes?
"It's necessary to agree on the main goal and expectations before developing something. Keeping that in mind, it will be easier to use Jira later and understand the logic of how things work," commented Ivar.
"For all companies that need to share and manage tasks between different departments, I recommend using smart solutions. Jira is an excellent tool for this," said Mari-Elts.
"For medium-sized and larger companies, I recommend using help from a consultant who is familiar with the product to help with the development and implementation of the software - it might not be possible to search and implement everything on your own. Before implementing the software, you should ensure that the company's project manager has free resources to work on the development. The process can be rather time-consuming," added the quality manager.
Jira Software beyond the IT world
Tech Group's implementation of Jira is a vivid example of how an application designed to manage software development projects can be successfully used outside of the IT world due to its flexibility.
"For the smooth introduction of a new solution, it is important for a company to have time and commitment. An open-minded approach to the ideas that arise during the process facilitates cooperation and communication, which altogether is a valuable step towards a high-quality final solution," Jürgen commented on the perspective of project management.
By now, the Tech Group has been using Jira Cloud for more than half a year, during which ongoing additions have also been made.
"Continuous improvement of solutions can be seen as a natural part of the process. In the course of active use, users come up with new and exciting ideas, and the software itself is also evolving in terms of new functionalities," concluded Jürgen.