Last week we took a look at cleaning up your fields to help improve your system performance. So now we move on to our next Atlassian TAM suggested topic: How to standardize workflows and screens. But before we dive in…
Last week was amazing. I had a lot of engagement on this topic, and even had two more people come forward with requests for more topics to write about. I’m always up to do a reader suggested topic, so if you have something you want to see covered, let me know! It may be a few weeks before I can write on your topic (For once, it’s nice to have a backlog!), but I’ll definitely get to it. You can use the contact form on the blog’s website, or email me directly at [email protected].
Anyways, lets get into it.
So, let me ask: Why would you want to standardize?
Fair question. This is going to be a lot of work, negotiation, and may come down to you telling them this is how it’s going to be. Why bother?
What’s the benefit that will make all this worthwhile? Well, the first benefit it helps teams within your organization work better together. If a person has to move from Team A to Team 1, they don’t have to relearn how to use JIRA. They’ll see the same fields and the same workflows. They’ll know how to use the tool as they’ve always have and be able to focus on getting to work that much quicker.
Secondly, It will help with reporting. With all the teams using the same workflows and fields, we have a consistent set of data across all teams with which to run reports and measure performance. While you should NEVER compare teams’ velocities to each other (as each team will value story points differently, therefore you will never get an oranges-to-oranges comparison), you can measure most other things consistently across the teams if they are all working from the same field set.
And the third, and I’d argue the most important reason to consider standardizing your schemes is your sanity. Look, there is only so much JIRA Admin to go around. If you are lucky, your organization has two or three of them to help out – but that’s usually for the largest organizations. Most small and medium businesses, it’s on you. Having standardize schemes stops you from having to play “What impact will this change have?”. You’ll know, and be able to get on with it that much faster.
But what about the exceptions?
Look. There will always be exceptions. A process or team that doesn’t adhere to normal business models. My Approvals workflow is such an example. But it’s your job to make it just that: An Exception. If you standardize your workflow, any change that is proposed by a team using the standard schemes should be measured on “How will this benefit the entire group?”. If it’s a benefit, it should be applied to the entire scheme. No breaking off a scheme to apply to a specific team. It’s all or none.
This, in and off itself, can help limit JIRA bloat. If a team has to defend why their change will benefit everyone, not just themselves, they will sometimes decide it’s not worth it.
So, where do I get started?
Honestly, I’d start with the screen schemes. And the first step is to talk with each and every one of your teams. Figure out what fields each one is using, and how they are using them. This will be time consuming – just a fair warning. But to do this successfully requires you to put in the work and really get to know your teams and how they work within JIRA.
Once you have that, sit down and compare your notes from all the teams. (You did take notes, right?) Find similarities, and try to get down to the fields you can get away with to allow as many teams to work as they already do as possible. Try to avoid fields that are used by only one team – opting instead to put that information in another field if possible, or the description. Take this time to use your test instance to make the changes. This will be both your testing and give you a way to demonstrate the change in a real way in our next step.
Now that you have your proposed standardized fields, this next step is probably the most important. Go back to each team, and present the new scheme proposal to them.
No, Seriously. Review what changes will impact their team specifically, and explain why you are making each change. Get feedback. Listen. Negotiate. Being willing to work with each team on this process is how you build buy-in, and it’s how you will make this process a success. Not everyone will be a 100% happy, and you may have to add some fields back in, but you can get them to a point where they can at least agree to the change. Again, I know this will take time, but having gone through this process myself, it is absolutely required.
So, you have con-census and buy in from your teams, and you have the changes ready to go in your test instance. You are now ready to push this to production..which in vanilla JIRA isn’t going to be fun. Without any plugins, you will need to manually recreate the new schemes in your production JIRA Instance, then assign all the appropriate projects to it. Or – you can use a tool like Botron’s Configuration Manager to copy over the new config as it exists from your test to production. Either way, I usually schedule a full change window for this during a relative down period for the instance (which invariably ends up being Saturday). No need having people try to work around you as you make these changes.
And that’s your Screen schemes standardized! When you are meeting with the teams, they may not understand why you are doing this. Stick with it – they will see the benefits eventually, and wonder why it wasn’t always like that.
But…uh…what about workflows?
Yeah…workflows. I hadn’t forgotten about it – I was strategically putting it off. I promise!
My experience has been standardizing workflows is a bigger fight than screen schemes, which is why I chose to lead with that. People are willing to be flexible on fields – most people don’t use most custom fields anyways. But when you start messing with their workflows, you are messing with how they work. And yeah – that is part your job – but it’s going to be a fight. So start out with the screen schemes and build up some good will. That will make this easier.
With the Workflow schemes at least, you have the information at hand for each team. Teams are somewhat free-form in how they use fields, so you have to interview them first. But a workflow can only be used as designed. So start by looking at all the workflows for the projects you wish to standardize. Figure out the common points, and design a workflow (in your test instance!) that matches as many of them as possible.
Now that you have something designed, take it to those same teams. Explain to them what you hope to achieve, and demonstrate how the standard workflow you are proposing differs from the one that particular team is currently using. Go through the same thing with each team you did with the fields. Explain the benefits of everyone working on the same scheme. The object here is to build con-census from the ground up.
Look, I’m not going to sugarcoat it. People are going to disagree with you. Some are even going to do so passionately. Don’t make enemies of these people. If they care about how JIRA is being used THAT much, they are a person to have on your side. Figure out what their objections are, and figure out a way to address or otherwise work-around those objections. But show you are willing to work with their concerns, and they will be more willing to work with you.
Once you have all the concerns addressed and con-census built, schedule a change window and put it in place. You can do it manually, or by a plugin. Honestly, I keep harping on the plugin as an option as it eliminates some possibilities of you making a mistake. But if you are going to do it manually, at least export the workflow and re-import it into production, so you don’t have to worry about a mistake there.
And that’s it!
Look, this won’t be the easiest thing to do as a JIRA admin. People can be very passionate about how they work, and if you are seen as messing with that, they can get upset. But remember that they are upset because they do care, so if you can show that you are willing to listen and work with them, it should help.
So I know everything else in the world has been going a little crazy right now. I really hope you all survived the transition and ramping up your teams to work remotely. I’ve been stuck at home anyways while I recover from the surgery, but even before that I’ve been a remote employee for some time, so it still business as normal for me. I can write a post on tips and tricks from working from home, but it’s all likely advice you’ve heard elsewhere already, so unless requested I don’t have a plan to write on that topic. But if you are interested, let me know!
Don’t forget you can subscribe to receive new posts from this blog via email! To subscribe, just put your email in the form below this post! We also have an officially Unofficial Atlassian Discord chat. Swing in, ask questions, and see what’s going on! https://discord.gg/mXuRsVu
But until next time, this is Rodney, asking “Have you updated your JIRA issues today?”
The Jira Guy 