Tell us about what your team was trying to achieve and how that informed the way you thought about your release management process.
At OTP bank, there are 8 product tribes (70 development teams) that are responsible for making improvements to existing tools and supporting 25 business departments (41 teams). I work in an independent tribe that builds processes that span the entire organization. We wanted to update our Jira Software instance and streamline the software development process so that the product tribes can better support the business departments.
At the time, our software development process was chaotic. Some teams used Jira, other teams didn’t. We had no understanding of the volume of work, and it was impossible to carry out high-quality grooming of tasks. Some of the main issues with the pre-existing process are as follows:
- There was no documentation. Nothing was written down. Processes were managed via word-of-mouth. There wasn't clarity on release criteria, task requirements, or roles and responsibilities.
-
The workflow was over-complicated -- There were a large number of statuses, different conditions, validators, and post-functions that did not reflect true business needs.
-
There was no standardized workflow -- Each product tribe had their own workflow, which meant there weren’t any common quality controls. This often resulted in miscommunications between the product teams and business departments.
-
There was excessive automation -- Changes were being made automatically. Since no one understood why these changes occurred, end users simply stopped following the process in Jira.
-
There was no process for prioritization -- Tasks were being served on a first-come, first-serve basis, but this didn’t always reap the greatest return and resources could’ve been better allocated.
Before making any major changes to the release management process, we conducted an extensive audit of existing processes and our Jira instance. We studied teams to understand who’s responsible for what, evaluated various tasks to understand the dependencies across different teams, and interviewed employees across the organization to understand their pain points and expectations.
Ultimately, we decided to move all business customers and product teams to Jira Software. We believed this would allow us to establish a single, standardized business workflow, provide end users with a flexible and convenient tool for planning IT improvements, and develop and implement a unified model for prioritizing customer tasks.
Tell me about the specific processes you implemented in Jira Software to drive towards that goal.
-
We made a strong-willed decision to go back to basics. Our previous instance was too complex and incomprehensible, alienating users from using Jira Software altogether. A simplified instance would greatly increase usage of and user confidence in the tool, thereby allowing all end users to speak the same language. Now, each product and business team has their own Jira project. All projects use a single-role model with only 5 main roles defined in the permission schemes: administrators, developers, sers, creators, sprint managers, and controllers. All projects contain 5 issue types: epic, user story, task, bug, sub-task.
-
We established links between the tasks added by business teams and the tasks selected to be completed by the development teams. Business teams create their tasks with the "User Story" type, while the product teams create their issues with the “Task” type. A link helps us align on the work we’re doing and reduces miscommunication.
-
We created standardized workflows for the business and product teams (see below).
-
We created a method for prioritizing tasks. When a business customer submits a task request, we determine the «Priority» (High, Medium, Low) based on when the task is needed by. Then, we assess «Severity» (Block, Critical, Major, Minor, Trivial) based on profitability, risks, and scale. Given the inputs, the «Order of the execution» field (values from 1 to 10) calculates and prioritizes tasks.
|
Business Teams’ Workflow
Most business teams only want high-level visibility into where their task is in the process, so we created a simple workflow with clearly defined statuses to allow them to track their tasks through completion.
Backlog - Tasks that are added to the backlog are assumed to be at the “idea” stage. They are not yet in production, but will be reviewed prior to moving forward. Business teams are encouraged to populate the backlog!
Analysis - Task is being reviewed by the product teams for possible dependencies, build requirements, etc.
Refine - Task requires clarification. The product team will collaborate with the business teams in the comments of the issue to resolve any questions.
To Do - Task is now ready to be implemented.
In Progress - Task is currently being worked on.
Review - Task is awaiting review by the business team who requested it or is awaiting delivery to the production environment.
Done - Task is resolved/implemented.
|
Product Teams' Workflow
We recognized that product teams have different ways of taking a task through to completion, so there is no single workflow for them. However, all
product teams follow similar processes, as there are several statuses shared by all teams.
The statuses shared amongst all product teams also align to some of the statuses in the business teams workflow:
Backlog, Refine, To Do, Done
|
Thinking back, what are some best practices you can share to help others with their own release management processes?
-
Spend time analyzing the current processes and communicating with the main participants in the process. Your users know a lot -- they know the pains and problems, and most importantly, they will be users of your new process! Try to act iteratively, getting timely feedback on the work you've done.
-
Spend time creating a prioritization scale that works for you and your company. There are many needs across a company, and there should be alignment on overarching goals. This will make it easier to groom tasks and plan releases. It is also important that there’s transparency around this prioritization scale so teammates understand where their tasks stand and can plan accordingly.
-
Document your processes regularly. Yes, it is a difficult and endless process, but it is mandatory. The list of teams and their compositions are constantly changing - you should always have an updated "single source of truth" at your fingertips.
In general, what are some pro-tips you could give to someone who’s a new Jira admin?
-
Take time to process requests before moving forward. Always try to understand the needs of users as much as possible, and then look for a solution.
-
Avoid unnecessary, non-obvious automation. Too much automation can cause confusion for your users, leading to lower engagement and usage. It can also be difficult for admins to manage. Simplicity is key!
-
Continuously educate your users on the correct use of the tools – how to search issues, how to create filters, boards, and dashboards, etc. We at our company do this through documentation and blog posts in Confluence, weekly demos, and meetups. Sharing knowledge is cool!
-
Do not stop learning by yourself. Use all the existing Atlassian Community opportunities: ask questions, answer questions, participate in discussions, read various articles, take part in challenges. Also, do not forget about the existence of Atlassian University, where you can always find useful and properly structured information. The more you know, the easier it will be for you to help your end users!
-
Continue to monitor the correctness of the processes and collect process metrics. This can help you address problems or deviations in the process in a timely manner!
-
Use process visualizations -- boards, dashboards, reports. It can be challenging to keep tabs on everything. Visualizations are an easy way to stay up to date.
Thank you for taking the time to read my story! Let me know in the comments below if you did something similar at your company or if you have tips and tricks of your own to share!
Connect with me on Linkedin.
Thank you so much for sharing your incredibly insightful story, Alexander! 🎊
#JiraHeroes have extensive knowledge of Jira, and share their thoughtful and tactical content with the Community! Are you inspired by Alexander’s story, or have a story of your own to share? Check out our call for submissions, and let us know you’re interested in the comments below to be featured and also receive our coveted Jira Hero Community badge! 🙌🏻
Do you want to become an Atlassian Certified Expert like Alexander? Learn how to get started here!
