So Long, Server

Rodney N.1 Comment

First, I should note a bit of a disclaimer: Opinions in this blog have been and always will be mine – and in no way represent the feelings of Coyote Creek Consulting or anyone other than me.  

Well, the writing has been on the wall for a while – but it seems that dreaded day is here. Last Friday, Atlassian announced that they would sunset the Server products. Starting next February, Atlassian will no longer sell new Server licenses. Three years after that, they will stop all support for Server products, including bug fixes and security updates. Afterwards, your options are Jira Cloud – which will be the only option for smaller teams – and Jira Data Center. 

I want to hate this decision.

On an emotional level – this is a gut-punch. I often say I try to be one of Atlassian’s biggest cheerleaders, but this week it’s been hard to be that. I started on Server because, for the longest time, that was our only deployment model. I still run a Server instance for Jira and Confluence in my home lab to support this blog. It’s how I’m able to capture a lot of the screenshots that I require for the blog posts. My licenses will come up for renewal before the price increases take effect, so I’ll be good for another year or so. After that – well, let’s hope I can get sponsorship. 

However, after running the numbers, I can’t hate it entirely. In the end, it will save most customers something. A few will pay more, and a few others are left out in the cold, but most people will save money. I will add this – if you plan on moving to Data Center, it will behoove you to go ahead and buy your licenses as soon as possible rather than wait for Feb. 2021. Those price increases are sharp, just saying.

So – let’s talk about those numbers.

Source: Jira Pricing, Future Server Pricing, and Future DC Pricing

I should note a few things here. First, I am only looking at the base Jira Software product, with no add-ons. This is not completely realistic, but it’s good enough for a comparison. I do intend to have an overview of how you can do a detailed analysis of your instance to figure out if Cloud is right for you next week. But for now, this will be good enough.

For Cloud, it is using the Standard Plan. I should also note that Data Center’s license model has a lot more tiers than Server does. So even though you might be on a 10K Server license today, it doesn’t mean you will have to go up to a 10K DC License. You might be able to get away with a 5K license if you have less than 5000 users, which would save you half that cost. Hence the asterisk.

Source: Future DC Pricing. Markup calculated as New Price / Old Price * 100

However, with a few exceptions, most people will save money versus their current Server Prices, so long as they are free to choose Cloud or Data Center. I fully get that not everyone is free to choose, but I’ll get to that in a moment.  

Now let’s get into it. As best I can tell, for the big three – that is Jira Software and Core Server, as well as Confluence Server – the prices are not increasing if you pay list price. If you are on a discount plan, your costs will increase, but that’s not most of us. The other Server products will see an increase, though, so it might make sense to review Atlassian’s docs for yourself.  

But back to the big three, the only costs that will increase are on the $10 Starter Package – which is going away entirely next February. That means you’d have to pay the next tier up – which is a hefty jump indeed. This one saddens me the most, as this tier is invaluable for people learning to become an Atlassian System Administrator. I’m sorry, but the Cloud is no substitute in this regard, just by the nature of being what it is.  

While this loss is sad, We can at least take a look at other scenarios to figure out how it will impact you moving forward.

So, About that Cloud thing you mentioned the other week.

Look, I don’t know how plainly to put it. Right now, if you are under 250 users, and Cloud is a viable option for you, you will save money on the Standard Plan over either Server or Data Center. This “break point” shifts when the new pricing goes into place such that anyone under 1000 users is now the winner.  

Now, I don’t care for Atlassian’s Cloud Product because it has its problems. No use lying about it, and that’s not what you come here for. However, Atlassian is investing heavily in it, and I don’t think the problems are unsolvable. And I’ve been given some sneak previews from Atlassian – exciting features are coming soon. So yeah, between Server’s End of Life and Data Center’s lack of smaller tiers, Jira Cloud is something to look into.  

However, not everyone has that luxury. This group was my first thought as I read through the announcement, and they still are. And I don’t think Atlassian is paying enough attention to them.  

Simply put, specific segments cannot move to Atlassian Cloud. Here in the United States, these include teams in the Financial Sector, Healthcare, Government work, and Education. The requirement here is almost always regulatory, which means this isn’t a preference. They are required by law to host their data.  

And this would be fine if Atlassian would provide lower tiers for Data Center. But as it stands, they won’t. So if a team happens to be smaller than the 500 user mark, they now have to pay for way more licenses than they need to meet regulations.  

And what about Data Center?

Look – the price increases set to take place for Data Center are going to hurt. Most are around a 200% increase in price. If you choose to move to Jira Data Center, you will be paying more over what you paid for Server after February. Just that, plain and simple. If you can lock in your license before then, you will be saving a good chunk of change for the year. So my recommendation is lock in those licenses early if you are thinking about going this route.

The good news here is you don’t have to redo your architecture to take advantage of a new DC license. You can drop it into your current Jira Server instance in place of its server license, and you’ll instantly unlock the new features associated with Data Center. From there, you can take your time to build out your infrastructure to make it a true Data Center instance – or not. All depending on your needs.  

Another thing to consider on Data Center is your license model is different. On Server, your license is perpetual. That means if you let it lapse, you can still run and use Jira just fine. You won’t be able to upgrade it to a new version or get Support from Atlassian, but it will still work. Honestly, I’ve heard from some companies that run their Atlassian tools like this – only getting a new Server license when they plan to do an upgrade and only doing an upgrade every few years. 

However, in Data Center, that’s is not the case. If you let your Data Center license lapse, your instance locks up, and you cannot use it until you get a new one. This is because Atlassian considers its Data Center license to be a “subscription,” which you need to pay annually. Just something to think over if you haven’t looked at DC before. 

Viral Marketing

So – as I mentioned last week, I can be something of a marketing nerd. And I’ve loved Atlassian’s strategy they’ve employed for years now. They’d start small in a given company. Maybe a guy used Jira at his old job, and he recommends it to his team. They adopt it, build on it, and it works for them. The next team over sees their success, adopts Jira, and it grows. Before you know it, an entire department is using it. But then Legal notices what it can do and wants in. So does HR. And Accounting. Now your full company is using Jira, and you have a large instance.  

This process is honestly how I see Jira adopted most often. It’s not a top-down decision; it’s a bottom-up grassroots movement. However, will this process still work if the teams start on Jira Cloud, where the license costs are per user? I don’t know if one team manager will want to foot the bill for another team using “their” platform. It seems Atlassian might be thinking more of the top-down approach is the future. Or they have data that says this isn’t a problem. As I said, I don’t know, but I’m going to pay attention to what I hear from the ground.

Remember, you have time.

Look, this announcement feels sudden. But don’t let it spook you. Jira Server will still be here for over three years. This period gives you plenty of time to evaluate all your options and move there before Jira Server has its End-of-Life.   

However, hasty and emotional decisions are rarely good ones. It’s one reason why I wanted to wait to say much publicly until I could calm down, get the emotion out of it, and figure out the real story here. Trust me when I say that my outlook on Friday was a lot more panicked than it is as I write this today.  

So stop, take a breath, and relax. You’ve got this. If you are on a Server instance, it’s not the end of the world. It’s just the start of the next leg of your journey. 

Questions from you

Considering I made no secret of today’s topic to everyone, I figured I’d open it up to Social Media to see if they had any questions. And of course, you guys came through. So let’s see what your concerns are?

“Did Atlassian make a good call to announce this change considering, that cloud is still very much not a mature platform yet?” – Vitalijus Šerpytis

Do I think this timing is ideal? No – not at all. Look, we are still in a massive global pandemic, the economy is in a global downturn as a result, and to have this enormous change on what most companies consider a vital resource during this time is…less than ideal.  

However, I also don’t think they necessarily had a choice. In a previous article, I made note that Atlassian is a relatively small company for their outsized reach and influence. And this small company has been splitting its attention between Server, Data Center, and Cloud for a while now.

And yes, we know Cloud has been getting the lion’s share of the investment for a while now, too. It’s where all the new “cool” features are premiered. However, Atlassian Cloud does have some fundamental problems. You know it, I know it, and you better be sure Atlassian knows it. And at their current setup, they don’t have the resources to fix that.  

Atlassian also sees data that says most new people to their products are starting in Cloud. This fact tells them two things: A) Their future depends on Cloud, and B) They don’t have the resources to fix Cloud and support Server and support DC.   

Between Server and Data Center, Server’s been trending downwards, while DC upwards. Of course, this trend exists – people are migrating away from Server to Data Center and Cloud, so it’s going to go down, but the data still is what it is. 

So given all the facts above, if you had to make the hard choice, which would you make? As I’ve stated, I think this decision does ignore some critical use cases, but I can at least understand the decision.

“How can customers trust Atlassian is going to offer DC going forward given all their actions in the last few years?” – @jonjonbling

Hmm, just asking all the hard questions. Look, I am not a part of Atlassian, so I cannot say what they are going to do with any certainty. However, Server and Data Center have a fundamental difference that makes Data Center more attractive to keep onboard: DC is a subscription license.

For Server, you pay once for your license; then, you pay a smaller “Maintenance” fee every year after for access to upgrades and Support. If you don’t plan to upgrade and don’t feel you need support, don’t pay Maintenance. You can still use your Jira instance because you’ve already brought your license. 

However, with Data Center, you pay the full price every year to continue using your Jira instance. It’s a subscription, so if you don’t pay it, you don’t get to use Jira. This pricing model brings in a lot more money to the company. It might be cynical of me, but when in doubt, follow the money. Atlassian has a lot more incentive to keep Data Center alive than Server, so it will likely be around as their “On-Prem” offering. 

Here’s to a better week coming up.

This week has been a long one. I don’t know what the future may hold for the Atlassian Ecosystem or this Blog, but I know that we are adaptable, so we’ll do what’s needed to move ahead. So, I’m not going anywhere, and I’ll do my best to guide you through what’s coming up.  

However, you can help now me out. If you are financially able and find this Blog helpful, consider becoming a Patreon and supporting what I do here. Depending on your monthly contribution, you can get access to a Members-only discord, exclusive content that I will not be posting publically, as well as recognition on the Blog. Higher tiers can even participate in a Monthly AMA Conference Call or even a private one on one (virtual) meeting with me. Patreon is very much an experiment, but if you find it useful, please consider supporting the Blog.

What are your thoughts? Are you angry, worried, or looking forward to the changes? Is your organization planning to migrate to another platform? If so, which one? Leave a comment on Social Media with your thoughts and help the algorithms distribute the Blog. You can find me on Facebook, Twitter, and LinkedIn, where you can find new posts, community news, and interesting tidbits. You can also put your email down below to get new posts delivered directly to your inbox. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

Jira 8.13 – Long Term Support Version!

Rodney N.Leave a comment

It is a glorious week, everyone! After nearly a year of running 8.5 as the last LTS version of Jira (formerly Enterprise Release version), last week Atlassian released version 8.13! This is likely the version that most serious customers will be running for the next year, so I thought I’d look at the new tricks and treats that Atlassian has in this release.

Wait, Long Term Support Release? What Happened to Enterprise Releases?

Yeah – it might be confusing if you don’t follow this stuff recently. Last June, Atlassian rebranded Enterprise Released into Long Term Support Released. The upshot is still the same – where possible, Atlassian will backport all bug fixes to this version for two years. That’s two years that you can make sure that your instance is safe and running without bugs – without having to worry about testing new features that may or may not break your company’s workflows. As a rule of thumb, I always go with the latest LTS release unless I have a very, VERY good reason to pick something else, like a critical feature that isn’t available yet. 

So, What do we get for upgrading?

In a word, a lot. If you have been stuck on an LTS Version, things don’t hold still. There have been seven other versions of Jira released since the last LTS Release; each chalked full of new features. While I intend to go over a few of the ones I’m most excited about for Jira Software and Service Desk – there is no way that I can reasonably cover every new feature. So – I won’t. 😛

Instead, I’ll post the links here to the full changelogs for you to review yourself. 

Jira Software

New User Picker (From Jira 8.12)

So, have you ever been searching for a user, and can’t tell which “John D.” is your John Steven Doe? I have – countless times. Jira finally fixed this in Jira 8.12 – giving us a User’s avatar, email, and Name in the search!

Image Courtesy Atlassian

Improved email notifications about mentions (From Jira 8.11)

So – I’ve touched on this before. Jira sends a lot of emails, and Atlassian has heard this cry. Now you can start seeing the benefits of this. Jira will no longer send you an email for every mention, instead adding it to a digest that you will receive. It will also move you up in the queue to receive the digest as soon as possible – but you won’t be flooded with mentions anymore. 

Image Courtesy Atlassian

OAuth 2.0 Support for Incoming Mail (From Jira 8.10)

Both Google and Microsoft are planning to disable basic authentication. We don’t know when as they are coy about the timetables – but it’s coming. However, up until now, Jira only supported Basic Auth for email. Thankfully, They are ahead of the curve and putting in OAuth 2.o support.  

Image Courtesy Atlassian

Dates on Future Sprints (From Jira 8.8)

Sometimes you need to plan ahead with your sprints. Up until now – you could only assign dates to the current sprint. That has changed. You don’t have to fill them out, but now have fields on future sprints for dates if so you want them. 

Image Courtesy Atlassian

Anonymizing Users for GDPR Compliance (From Jira 8.7)

GDPR Audits as a Jira Admin is just painful. I don’t think I’m alone in thinking that. Now it’s just a little less painful. As an administrator, you can no completely anonymize a user’s record within Jira. This is a one-way operation, so if you do this by mistake, there is no recovering that user’s information, but it will honor a user’s “right to be forgotten,” which is a happy tick off the GDPR Audit. 

Image Courtesy Atlassian

Jira Service Desk 

Jira Service Desk support on Mobile (from JSD 4.12)

This feature is still in beta, but it’s exciting. Now you can have native Jira Service Desk support on the mobile Apps for iOS and Android. To get this rolling, you will need to enable the option in Jira, but once you do all your agents and users should be able to access the new features on their mobile devices.

Image Courtesy Atlassian

Multilingual customer portal and help center (From JSD 4.11)

Not everyone speaks the same language. If you run a portal used by a world-wide Enterprise, a person speaking any number of languages could be accessing your portal. Now Jira Service Desk comes with multilingual support in both the Portal and Help Center. This feature will allow your customers to access Jira Service Desk in the language they speak. You can even add custom languages or translations.

Image Courtesy Atlassian

Improvements to agent queues (From JSD 4.6)

This feature has been much needed. Atlassian has taken a look at the Agent queues and improved them. For one thing, you can now sort by columns to find the most critical issues to address first. And what’s more, the sort you apply is specific to your account, which means you won’t affect how your teammates sort their issues and find what works for you.  

They’ve also added keyboard shortcuts to the queue screen so you can use arrow keys to hop between different issues in your queue. 

Image Courtesy Atlassian

And that’s not all!

All told, if you are upgrading from the previous LTS version to this one, you will be getting some 27 new features for Jira Software and a whopping 42 in Jira Service Desk. Some of these are from Jira Core, so they are duplicated between the two. But that is a whole lot of new toys for your teams.

A new LTS version is something to celebrate. I mean, who doesn’t want new features on a platform you know you’ll be able to maintain for a bit? Back before Enterprise releases were a thing, I often felt you needed to upgrade every six months at a minimum to keep up. And then there came Premier support “blessed” versions to keep track of. Which weren’t a particular release, only a version that Atlassian’s Premier support team had tested and felt was a bit more stable than the rest. But honestly, this just felt like another thing to keep up with – you still needed to upgrade aggressively. 

Having the ability to step back and not do a major upgrade as often is very much a load off of my feet. Yeah, there are still bug fixes to test and apply, but as they don’t include new features, the testing on those is much less demanding.

So what do you think? Are you planning to upgrade to the latest LTS Release? If so, what features are you looking forward to? If you enjoyed this post, help the algorithms by leaving a like and comment on social media of choice. You can find us on Twitter, Facebook, and LinkedIn, where we post new posts, news from the community, and anything I find interesting. You can also subscribe below to receive the latest posts directly to your inbox. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

What’s the deal with Jira Cloud?

Rodney N.Leave a comment

So, a few weeks ago, I was contacted by Jira Gal Heather Rimmey. She had seen a comment I had written in reply to someone’s comment about Jira Cloud and Jira Server. It turns out she was having the same discussion with management and wondered if I had any thoughts on the differences between the two deployment models. And well, we all know I do! This week, let’s dig into the differences and discuss when one option may be preferable to the other. 

As a note, I’ll be using “Jira Server” a lot during this post. Please understand it to mean Either Server or Data Center. While the two are very different deployment models and have unique feature sets, it’s an excellent grouping to keep this post from getting too confusing. 

One is not better than the other.

Let’s get this over with first. I do not think a Server Deployment is better or worse than a Cloud deployment. However, I believe that they are very different creatures who both happen to bear the name “Jira.” That is to say, just because you have experience with Jira Cloud doesn’t mean you’ll transition smoothly to a team using Jira Server and visa versa.  

That’s my most significant point, and one I cannot stress enough. Most groups I talk to fail to consider a certain “relearning” time that will cause overall productivity to go down after a migration. Your teams will need to learn how to do all the things they knew on the old platform. This can be offset a bit by training, but only to a point. It’s something to consider.

Control vs. Ease of Use

This concept, as I see it, is the main selling point of Jira Cloud. You don’t have to learn how to set up a server or run an upgrade. You request your site, and within moments you have a Jira instance! Congratulations.  

And this is great! If you are a small team, you don’t need that overhead. However, just like everything else Jira, this is a trade-off. Atlassian is continually pushing out updates and upgrades to Jira Cloud. This model means you often get not only bug-fixes first, but the latest and greatest features that the On-Prem deployments may not receive for months or years. 

But what happens when Atlassian pushes an update that breaks your processes? Like when they pulled the Cloud version of the Automation for Jira app before the built-in version was completely ready? Don’t get me wrong, I have staked my career on Atlassian’s products, and will be their biggest cheerleader as a result, but sometimes “oops” happens.

With a Server deployment, I can find these “oops” moments in a testing phase of an upgrade. I can then choose to hold off the upgrade until I find a workaround or Atlassian fixes the bug. But you don’t get that luxury in Cloud. The best you get is the ability to put off an upgrade by a few weeks – but only on their highest-tier plan.

Again, not saying this a bad thing. It’s a trade-off for getting all the new toys before the rest of us. But it’s definitely something to consider. 

Site Names

This fact maybe just me, but I’ve always been fascinated by Product marketing and branding. As my wife will attest, if I find an interesting product packaging at a grocery store, I will derail the whole thing for a moment while I take a closer look. I’ve honestly purchased some products before so that I can take a closer look at its packaging. It’s kind of sad and funny at the same time.

What does this have to do with Jira Cloud? I’m getting there. Every Atlassian Cloud instance has the following URL Structure: <yoursite>.atlassian.net. What if you prefer jira.thejiraguy.com? Too bad – can’t do that with Cloud. At some companies, this isn’t a big deal. You can still have your company name somewhere in the URL, and that’s good enough.  

But that’s not every company. Some companies feel having their URL there is essential for customer perception. I can’t say I wholly disagree with this idea, either. I intend to eventually do a review on a tool that allows you to put public sites (like Atlassian Cloud) on your domain, but even that is just a workaround.  

However, on Server, that is the point. You set it up on your servers, so you will need to have the URL set up, too. So you can use whatever URL you have control over. 

Scaling

This is a point I think Jira Cloud does a great job on. Look, no matter how robust your system is or how much care you take over your configuration, if your userbase continues to grow, you will eventually outgrow your single server instance? What then?

Well, you are looking at a migration to Jira Data Center. This process presents its own hurdles and challenges. Just like a Server to Cloud migration, not all Apps that are available for Server are also available for Data Center. You will likely have a larger instance at this point, which means you might be trying to move a large amount of data around. Not fun.

And what do you have to do to scale Jira Cloud? Either pay for more users, or on the odd occasion, pay for a higher tier. That sounds a heck of a lot easier to me. 

Apps

While this will be my last topic today, it is not anywhere near the last difference between the two deployment models. I’ll be including some additional reading if you want to explore all the differences yourself. 

However, I’ve already touched on this one in this article, and it’s probably one of the most annoying things about the deployment models.

Jira Server Apps are not compatible with Jira Cloud, and visa versa. What does this mean functionally? It means that if you are considering moving from one to the other, you have to sit down and look at every single App you are running and determine if they have an equivalent on the other model. And most of the time – there will be at least one or two Apps that don’t. 

Then your job is to sit back down and determine if another App is available to give you the same functionality, or failing that, determining if you can live without that App. And honestly, having to find out if you can “live without” happens more often than not. 

There is another effect to this incompatibility. I cannot count how many times I am searching for a plugin to solve a specific problem, and I finally find the perfect App. It’s well-reviewed and has a large install base. And the documentation is thorough and doesn’t look too involved. Then I look up and realize it’s only for a whatever deployment model I’m not on. It’s honestly enough to drive one mad sometimes!

Further Reading

As I’ve stated earlier, these are far from the only differences. However, if I were to write on every difference – and the practical effect of each one – I’d be writing a book. However, if you are interested in reading further, I do have two links you would be interested in. The first is a high-level differences in the Cloud platform for all the tools. The second is more specific to Jira.  

Look, if you are considering moving to the Jira Cloud, or just want more information before committing to a platform, I encourage you to read through both carefully. Figure out what trade-offs you can live with and what you can’t. Jira Cloud may suit your needs very well. Or it might have several deal-breakers. The only way to know is to do your research!

And that’s it for this week!

Before I forget, big news from this past week! Atlassian announced that they are renaming Summit 2021 to Team 2021! I don’t think we know if this will be the same once we can meet in person again, but I’m still excited. They have also opened up submissions for Speakers for Team 2021. I’ve put in three presentations from some of my favorite posts over the past year, and hopefully, I can get selected! If you have any interesting ideas for presentations, breakout sessions, etc., why don’t you submit too! Nothing ventured, nothing gained!

Image

However, if you’ve found this post helpful, why don’t you give it a Like? I post new articles every Wednesday, so you can sign up below to get it delivered directly to your email inbox! You can also find me on Facebook, Twitter, and LinkedIn, where I’ll post updates, news, and new posts – so be sure to follow! 

Is Jira feeling slow lately?

Rodney N.Leave a comment

Well, last week. Where do I begin? Maybe here:

Yeah, pretty good, right? I thought so too, then Thursday happened:

Just Wow. Thank you, guys! I keep finding that just when I see the ceiling for this community, you guys go and surprise me like this.

On top of the page views last week, I also had a number of you reach out to me last week for various reasons. However, one drew my attention in particular.

Well, Harsha, it’s been a while since I released a System focused post, so challenge accepted. Fair warning, though – this topic gets intense. Jira is a rather complicated system. Even if we ignore the configuration and focus on the system, there are still many places we need to check out to know what bottleneck is causing Jira to perform slowly. But too late, you’ve already asked for it, so let’s dive in.

Lag Sources

CPU

Well, this should have been obvious as the first place to look. If your CPU is overloaded, it’s going to impact performance for the end-user. It amazes me how many people skip looking at this and head directly to adding more Heap Memory to the JVM (which we’ll talk about in a moment). If you are on a Windows Server, you will likely know how to check CPU on it via the Task Manager’s Performance Tab.

This utility will also give you information on Disk Throughput, Memory usage, and Network utilization – all good indicators if you are trying to diagnose slowness in your Jira instance. However, on Linux, I prefer to use the top utility.

This tool will tell you many of the same things, but it requires some know-how to interpret. So why use top instead of something like glances or htop? Well, it’s because top is an almost universal tool on Linux systems. It is so rare that I encounter a system without it that I cannot actually remember it. So how do we interpret this data?

The first thing I usually look at is the load average. This measurement is broken down to load over the past 1 minute, 5 minutes, and 15 minutes. Ideally, this number should not get over 80% of the number of CPUs you have. Do you have 4 CPUs? That number shouldn’t be above 3.2, for example. It’s not an exact science, but it’s close enough to work as a rule of thumb.

Another place we can look at is the CPU Utilization, underlined above. These numbers are broken down into various categories, as shown below.

us: user cpu time (or) % CPU time spent in user space
sy: system cpu time (or) % CPU time spent in kernel space
ni: user nice cpu time (or) % CPU time spent on low priority processes
id: idle cpu time (or) % CPU time spent idle
wa: io wait cpu time (or) % CPU time spent in wait (on disk)
hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts
si: software irq (or) % CPU time spent servicing/handling software interrupts
st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine

The two we are most interested in is “us” – this will be the active Jira Processes, and “wa” – this will alert us to a slow disk problem. These measurements are broken down as a percentage of the total CPU capability of the system – so they all should add up to 100%. So if your us measurement is taking 80% or more of the total system usage, you are using too much CPU.

So, the answer is just adding CPUs, correct? The answer here is maybe. If you are on a VM, it might hurt more than help. How so? My understanding here is that the Hypervisor (that is the VM Server) will only schedule a given cycle for the VM if it has enough CPUs free for that cycle. Therefore, the more CPUs are allocated to the VM, the more the Hypervisor has to free up, and the more time between cycles on your VM. How much is the max for your Hypervisor? I cannot say, but your Hypervisor Admin should tell based on the VM Host’s CPU Utilization.

What if the wa value is high instead? This event is a sign that your disk speed may be limiting your system performance, at which point we’ll need to look at your disk speed – which we’ll discuss below.

Heap memory

So let me say – Atlassian already has an excellent video freely available on this. It’s called “Trash Talk! How to reduce Downtime by turning Garbage Collection,” and I still reference it to this day. Seriously give it a watch.

Oh – you’re still here. Well, this is awkward. I thought everyone would have gone off to watch the video. Seriously, I was at that talk at Summit 2016, and I still refer to this video as a refresher. If you are a Jira System Administrator, you oh it to yourself, your users, and your career to learn how to tune the JVM. 

So what are the take-aways from the video? First, don’t try to change the GC Method or any of the GC Parameters. Atlassian sets these to settings that will work for 99.9% of cases. I usually only touch them if asked to by Atlassian support. No – what I typically tune is just these two numbers.

As a best practice, I like to set them equal, that way the JVM will reserve it’s max amount of memory on startup. This way I won’t be surprised in a day or two by an out-of-memory error (or worse yet, the system deciding to just kill the JVM process.)

The second takeaway is that it is entirely possible to cause performance problems by setting the Heap Memory too high. Doing so can cause one of two issues. In the first problem, you end up choking out legitimate system processes from Memory, slowing down the whole System by forcing it to use SWAP space. In the second, the JVM wait’s longer to do a Garbage Collection, which means that GC Cycle will is more likely to be a full GC where the System has to pause the JVM. If the JVM is paused, it is not serving Jira Pages…hence the lag.

So, how do we know what number to set it too? We have to run it for a while, then analyze the GC Logs to find that out. If we see that the JVM is doing Garbage Collections too frequently, we need to bump it up. If we see that the GC’s are pausing the JVM, we might look at bumping it down a bit. Unfortunately, there is no hard-and-fast rule that says, “If you have this many users, set it to this.”

Fileshare/Disk Speed

Now you know the CPU isn’t overloaded, and the JVM is tuned correctly, but your System is still slow. Where do you look next? Well, the file system. I alluded to this previously, but you can get a clue if your System is having some Disk Access issues by looking at the wa statistic in top. However, while that will help if it’s high, it can give a false negative.  

The Good news here is that Atlassian gives us a guide on how to run a Disk Access Speed Test.

Basically, this will have you download a jar file from Atlassian Support, and run it against the location where Jira’s Index resides. Should look something like this:

 wget https://confluence.atlassian.com/jirakb/files/54362304/54591494/3/1444177154112/support-tools.jar
java -Djava.io.tmpdir=<Jira Home Directory>/caches/indexesV1 -jar support-tools.jar

If you run this, you should get a table like the one above. I typically look to the Median and Max columns, and compare against the table Atlassian provides (copied below).

StatisticExcellentOKBad
Open< 40,00040,000 – 150,000> 150,000
Read/Write< 40,00040,000 – 100,000> 100,000
Close< 20,00020,000 – 100,000> 100,000
Delete< 50,00050,000 – 300,000> 300,000

As we can see from my results, the medians are either in the OK or Excellent Range. However, my Max times are not (Also, OUCH on the Open Max). This result was likely an outlier caused by a problem on the VM Host, but cannot be ignored outright. If this were an enterprise setup, I’d start asking the VMware Admin questions to figure out if there are any problems with the storage and if we can speed it up at all.

My result is because I am running on seven-year-old hardware disposed of by some company as end-of-life and cobbled together by someone who is still learning.  

Database

So, this will be a radical idea, but sometimes Jira’s slowness isn’t caused by Jira. Sometimes it’s caused by an external system. No, seriously, how well your Database performs will have a MASSIVE impact on how well Jira performs.  

Atlassian thankfully also has a tool for this situation.

Again, this will have you download a jar and run it on your Jira server.

wget https://confluence.atlassian.com/jirakb/files/54362302/54591493/2/1444177155911/atlassian-log-analysis-0.1.1.jar
java -cp PATH_TO_THE/atlassian-log-analysis-0.1.1.jar:PATH_TO_YOUR_JDBC_DRIVER_JAR \
com.atlassian.util.benchmark.JIRASQLPerformance \
YOUR_DB_USERNAME YOUR_DB_PASSWORD \
JDBC_CONNECTION_STRING JDBC_DRIVER_CLASS \
> db-perf-test.txt

You will get the YOUR_DB_USERNAME, YOUR_DB_PASSWORD, JDBC_CONNECTION_STRING, JDBC_DRIVER_CLASS settings from your Jira instance’s dbconfig.xml file. A note on this tool: you need 1000 issues in your Jira instance to run it, as I found out the hard way.

However, Atlassian does give you an example of what the output should look like.

TOTALS
----    ----    ----    ----    ----
stat    mean    median  min max
----    ----    ----    ----    ----
retrieve-issue  5,338,000   979,000 213,000 46,007,000
get-issue   174,775 93,000  62,000  11,621,000
retrieve-workflow   5,117,153   607,000 341,000 47,738,000
get-workflow    98,996  64,000  40,000  2,962,000
retrieve-custom-field-value 601,093 495,000 316,000 23,082,000
get-custom-field-value  91,246  52,000  37,000  3,453,000
----    ----    ----    ----    ----
All times are in nanoseconds.

Atlassian states they don’t have an “Excellent, Good, Bad” chart for DB Values clearly defined, but they tend to look for any values below 20ms as good, and 10 ms as Ideal. (Remember, 1ms = 1,000,000 nanoseconds).

Network

Well, it’s not the CPU, it’s not the Memory, File System, or Database. What does that leave? Well, the network can be a bottleneck. You can usually check this with a simple ping test. Does the ping take a long time to reach the Server? Then you are more likely to see issues with Jira’s speed.

Look, I get it. You might be in India, and your company’s Server is located in the United States. You are only ever going to get your pings so low. If you are on Data Center, you can use a CDN to help with some of that latency, but it will take actual time for the packets to travel around the world. 

However, if you are located in the same building as your Jira Server and are still getting high pings, it might be time to talk with your Network Admins to figure out what is going on – especially if you’ve run all the test to say it’s not the Jira Server itself. 

Maybe it’s just busy.

Look, I’ve done my best to ignore the Jira Configuration in all this and focus solely on the System. However, you will get to a point where it will become impractical to add more Memory or CPUs to a server. At that point, you have two real options.  

For your first option, You can do the hard work and clean up your configuration. Get rid of unused workflows and permissions schemes, consolidate duplicate custom fields, and get Jira healthy in that regard. It’s not easy, and may not be politically expedient, but it is well worth it.

Your other option is to migrate to a Data Center Architecture. Look – there are only so many users a single server can handle. Data Center Edition solves this by spreading the load out to several servers, each working together to form a single Jira instance. I have several articles already on how to convert your Jira server instance into a Data Center instance. So if this sounds like you, maybe it’s time to consider an upgrade. 

Well, there you go!

Look, this is an involved topic. Pinpointing your performance issue to a single cause is tough – especially when it’s a real possibility that there are several causes. But it’s well worth it to go through each of these and see how your System is doing. 

This week has been a busy one. I haven’t had a chance to read as much or do research like I usually like to do. So, I only have one webinar to share with everyone this week. “Get Jira superpowers: Reporting on Projects and Calculated Fields” is a joint presentation by Deiser, Old Street Solutions, and cPrime. And it’s tomorrow, 11:00 AM Eastern time! You should check it out!

As always, if you enjoyed this post you can subscribe below to receive new blog posts directly to your inbox. You can also like, follow, and comment on social media to help your colleagues discover our content! You can find me on Twitter, Facebook, and LinkedIn with regular updates, new posts, and news about the blog. But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

Rules of Thumb

Rodney N.Leave a comment

The Merriam-Webster dictionary defines a Rule of Thumb as:

What does this have to do with Jira? A fair bit, honestly. While not hard and fast rules, these concepts can help you find your teams’ best solutions. A friend of mine suggested this topic, and I loved the idea. However, I was having a problem finishing out the post, so I had to turn to the community for more ideas. And you guys delivered! As such, I’ll be putting the source (or sources) I heard of these rules from. So let’s dive in and see what we can learn here!

1) If your workflow takes more than 30 seconds to explain, it’s too complicated. – Logan Hawkes (Coyote Creek Consulting)

So, this one is relatively straight forward. The idea is that your workflow should be simple enough that you can explain it quickly to your colleagues. If your workflow sounds like “First it goes here, then it gets assigned to this person. However, if this thing is checked, then it’s assigned over here instead. After that, it goes back here for approval before going here to have some action performed, and then it’s transferred to that department for final analysis.”

Yeah, that’s not going to make the 30-second mark. I doubt that it will survive a dedicated meeting. Let us not forget that this workflow would not only be impossible to communicate; it would also be a nightmare to maintain as well.  

That ultimately is what this rule of thumb is meant to protect you from. A workflow you can’t explain effectively and can’t maintain easily does no one any good.  

2) If your workflow has ten or more steps, it’s too long. – Logan Hawkes (Coyote Creek) & Matt Doar (LinkedIn)

So this is another rule of thumb meant to protect you from an overly complicated workflow. The idea is simple – if your workflow has too many steps, your users will not want to use it. No, seriously, put yourself in your user’s shoes. Would you like to progress through a workflow that has twenty or thirty steps? I have better things to do.  

The number is a bit arbitrary, but it’s about spot-on. More than ten and your workflow starts to look like a mess. Below nine, and it seems doable. So as far as rules of thumb go, this looks to hit the sweet spot.

3) If you have to scroll more than twice on a screen, it’s too long. – Logan Hawkes (Coyote Creek)

This one also goes into the same category. I touched on this previously with my “Jira Sucks” article a few weeks back. Having too many fields on a screen doesn’t capture any more useful data, discourages your users from using the system, and all-in-all just looks terrible. But where do you draw the line? What number is “too many” and what is “just right.”

That’s where this rule tries to help. Rather than giving a hard number, it gives you some criteria. Two scrolls will vary user to user, but it’s close enough to provide you with leeway in making your screen.

4) If you have more than 1000 issues in your backlog, it’s a history book, not a backlog. – Sean Blake (Easy Agile)

I have seen this all too often, and I’m sure you have, too. That project that collects backlog issues like they are a collector’s item, with the “Yes, we’ll do all this someday” attitude.

Basically, your backlog grooming meetings looks like this…

If this rule of thumb applies to you, it’s time you had a hard conversation about reality and priorities. It’s time you decide what you do intend to do, what are lovely ideas but not feasible, and what you need to mark as “Won’t do.”

It might also be time to look at your process and add a triage step to filter out some noise from entering your backlog. Otherwise, you’ll wind up back here in a few months anyway.  

Let me make myself clear here. If you take in public submissions for bugs, feature requests, etc., you’ll find this number to be laughably small. However, this rule of thumb isn’t meant for these kinds of queues. It’s intended for your team backlog, which should never grow that long with work waiting to be done.  

5) If you need something more than labels and components to divide your work, review your process. – Jesus Oros

This one would drive me crazy. You’d have that one manager who would insist that they’d need more to be able to organize their work. It’s usually more fields, but sometimes it’s also more issue types, and on rare occasions, it’s weird workflow tricks.  

However, all these divisions evaporate when you look at their process. The manager has put all of these artificial walls up that doesn’t exist. And if they do, they can use Labels or Components’ existing functionality to describe and sort accurately.  

Look, a complicated process helps no one and makes life more challenging. The complications may have been thought up to try to make life easier, but they rarely do. This problem is why – save for infrequent circumstances – I still recommend a relatively simple workflow and project settings for most teams. What’s there already is flexible enough to organize work for most groups while still allowing it to accommodate 99.999% of situations.

6) If you don’t plan to either require it or report on it, it doesn’t need to be a custom field. – Rodney Nissen (Coyote Creek)

This one goes under “just because you can, doesn’t mean you should.” I get it. Custom fields are nifty. They are one of the things that makes Jira unique in its niche. But you don’t always need a new custom field for everything.

Let me explain. I once had a request come in for ten new fields. They were as such:

  1. Process Details
  2. Shipping Address
  3. Cost
  4. Shipping cost
  5. Reason Needed
  6. Rack Assignment
  7. Rack Position
  8. Purpose
  9. Shipping Date
  10. Received Date

Okay. So, I can immediately tell that 1, 5, and 8 are things that can and should go into the Description of the issue. Upon asking some questions, I found out that 2, 4, 9, and 10 are not going to have reports run on them, and are not required for every issue, so they can also go into the Description when needed. So within a few minutes of thinking and some questions, we have already eliminated seven of the ten, which leaves us with Cost, Rack Assignment, and Rack Position.  

Cost will be needed on every request here, as will the Rack Assignment and Position. Furthermore, they plan to run a report on the Rack Assignment field to see what work has been done on which rack (to identify problem children). Those three pass the test and had field made for them. Yes, the analysis will take some of your time, but your teams will thank you in the long run, as will your Jira instance. 

 

7) If you are creating a provision to happen once a month or one out of 100 issues, you should not be making a provision for it. – Jesse Wisener (Coyote Creek)

This idea comes from the idea that you, as the Admin, only have so much time. If you are going to spend time on an automation, provision, workflow trick, etc., it should be on something used often enough to matter. But what is that cutoff point? When is something used often enough?  

Well, either once a month or once in 100 issues seems to be the happy medium. That is often enough that it will make a noticeable difference in your user’s lives, but still justify the time you’ll spend on creating and maintaining it. Some people won’t like to hear this. But no one else will do the cost/benefits analysis for you, trust me on that. 

8) Start as simple as possible and only add complications to alleviate pain points. – Jesse Wisener (Coyote Creek)

This one I’ve alluded to several times, but here it is in all its glory. You should have a good reason to add anything to your setup. Workflow, field, permissions scheme, anything. Essentially, you should always seek to deliver the simplest solution possible. 

Why? Well, for one thing, it’s easier to understand. You won’t have to be spending meeting after meeting explaining the solution to team after team. 

And another thing, whatever you make, you will also have to maintain. The simpler things are, the better chance you have of not having something break during an upgrade.  

Also, it will lead to adoption. You rarely hear, “Yo, there’s this team that has this super complicated deal, maybe we should look into it.” More often than not, people will seek to adopt and use things that they see are easy and working from other teams.  

So yeah, as my Engineering professors would hammer home, “Keep it simple.”

9) Value your own time as much as you value others, and visa versa. – Rodney Nissen (Coyote Creek)

I’ve had to learn this one the hard way. Some people won’t value your time if you don’t value it yourself. For example, I made the mistake of letting people at a company know that I can use the CSV importer to bulk-create issues. One project manager went a bit crazy with that, and at one point, send me a CSV sheet with only 17 issues. He valued his time so much and mine so little that he felt it wasn’t worth it for him to make that relatively small number of issues. 

I had to push back a bit, and even get his manager involved (to which his manager said to him, “You’re joking, right?”). However, it would also be easy to take to the other extreme and refuse to do anything because your time is too valuable. That is not what I’m saying.

What I am saying is that it’s a balancing act. People will need your help with the Jira instance, but you can’t let them take all of your time. Just find a common-sense point where it’s reasonable for you to help without being pushed around.  

And that’s it for this week!

This post is nowhere near an exhaustive list, so I can see this being a recurring segment we return to every so often. I want to thank Logan Hawkes for both the original idea and some of the first rules to include. I just loved this idea for a post that I had to do it as soon as possible. I also want to thank everyone in the community who helped out so much in this. I knew the number of Rules I wanted, and I wasn’t coming up with enough on my own.  

I loved the response to the various links I posted last week, so I figured I’d keep that up for this week. First up is a webinar/ACE virtual event, “The things that should NOT go in your Jira.”  Matt Doar, Toolsmith at LinkedIn, will give this presentation on Oct 2. It’s a bit early in the day for the U.S., but it should still be well worth it to listen. 

The second link I thought was interesting was an article titled, “Archiving Jira issues helped this government agency comply with privacy rules and keep Jira clean.” Yeah, it’s a mouthful, but I thought the topic was interesting. It is a reasonably good look at how they set up the system to archive issues when triggered.  

Don’t forget, if you’ve enjoyed this post, subscribe below to receive new posts directly to your inbox. Be sure to Like, follow, and comment on Twitter, Facebook, and LinkedIn, where I’ll post updates from the blog, news from the community, as well as the occasional plea for help on future articles! But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

Jira Blunders!

Rodney N.1 Comment

Last week I got a call from my family. Trust me; this does have something to do with Jira. My Mom told me that my younger brother of 17 was having problems with his Chemistry homework, and she wanted me to go over it with him. Being 17, he protested saying he didn’t need my help because he “had used a calculator.”

When I put my foot down and brought him into a Zoom meeting, I found that he had used an incorrect formula. This situation meant that while his math work was right, the answer was still wrong. I sat him down and explained his error to him, to which he stated he had hurriedly copied down the formula wrong at the end of a class.

I then asked him, “What did you learn?” He replied he needed to double-check his formulas. So what does this have to do with Jira?

We all make mistakes. It’s both very human and part of the learning process. However, not taking away a lesson on it is just a waste, which I was trying to impress on my little brother. The same goes for Jira. There will be blunders. This week, I am reviewing some blunders both I and colleagues have made to get a chuckle and help teach some important lessons.

Always Double-check system commands

So this didn’t happen to Jira – but it just as easily could have. I was working on a Perforce upgrade on a system. As part of this upgrade, I needed to upload a new directory to the server, then change its permissions. This server was a Linux-based system, so I was working on the command line as per my habit. 

So I uploaded the directory and its files, and then I went to change the permissions so that the perforce user could access those files. This is where disaster struck.  

This was the command I meant to run:

chown -R perforce:perforce ./

And this was the command I ran:

chown -R perforce:perforce /

Catch that change? One tiny little dot missing. For those who may not know, a “./” in Linux is shorthand for, “The folder I am currently in.” However, “/” , when paired with a -R, is shorthand for “Every file on the system.” This slight error meant that every single file on the system now belonged to the perforce user. But it gets worse. So, so much worse.

This exercise took place during work hours and was meant to stage some files ahead of a weekend upgrade on Production. Which meant I had just made a catastrophic error, on Production, in the middle of the workday.

I eventually realized my mistake when the change command took much longer to process than it should have. Even then, I’m embarrassed to say it had processed a fair bit of the filesystem before I realized my mistake. So, damage control mode. I changed most of the filesystem back to root ownership, save for the processes and files I knew to be managed by other users. Somehow I had it all back to normal relatively quickly. The miracle is that no one attempted a push to Perforce during all this, so my mistake went otherwise unnoticed.

So, what lesson did I take away from this? Well, if I am on Production, I do not free-hand commands. I write them out ahead of time, then copy & paste them into the terminal while working. Even if it’s a minor task, Production is sacred ground – treat it as such.

Label Your instances Carefully

This one was another mistake of mine that took place in the middle of the day. We were having some problems with our Jira system, so I was engaging with Atlassian Support to see if we could resolve them. Atlassian had helped us identify a possible culprit, but we needed to test changes in a Development environment before pushing changes to Production per our policies.  

However, our change controls for Development was – how do I put this – non-existent. Which meant I was free to go into Dev and make these changes whenever. So I decided the 11:30 AM on a Tuesday was a perfect time!

Now, when I’m a Windows PC, and I need to connect to a Linux Server, I’ll use mRemoteNG. It’s just a handy tool to manage all your system connections and work with individual systems as needed. However, this is how I had labeled and set up my connections at the time.

Can you see where this is going? Yep. I connected to “Dev” and started making my changes. I double-checked all the changes against Atlassian’s ticket, and once I was happy, I restarted Jira. Then I started getting questions.

“Hey, is Jira down?” “What happened to Jira?” “Is Jira down for you too?”

With a cold sweat, I looked over to my connection and realized my mistake. I had just made these changes to – and restarted – Production. And given our hardware at the time, Jira would be down for another two or so minutes.  

If there is something I do well, it’s handling downtime. I let my team know what had happened, and that Jira was coming back up. Yes, embarrassing, but I would have time to be embarrassed later. They ran interference for me while I did the last few steps to bring Jira back up and running. Crisis averted.  

So what did I learn? That day I learned that I needed to do a better job of labeling Production and Development systems. I also needed to put safeguards to ensure that I realize that I’m connecting to Production. After that day, this is how I started organizing these systems. 

I also removed the stored password from the Production systems so that I would have to enter it every time I connected to these servers. This process would serve as an extra layer of “Something is not right here,” which would hopefully prevent me from making that mistake again. And well, so far, it’s worked!

Oh, and if you were wondering, the new settings did fix our Jira problems, so there’s that happy ending.

Leaving your email on while Load Testing

This one came from a colleague at work. I’ll often ask for input or bounce ideas off my fellow East Coast consultants at Coyote Creek. This entire article started as one of their ideas!  

Anyways, one of my friends was doing some load testing on Jira for a client. He had just cloned their Production system to create a Development environment; that way, he could do his testing without impacting users. All per best practices, so nothing wrong there.

So he then turned on JMeter and started creating hundreds of issues on Jira. However, when he cloned Production, he had forgotten to turn off outgoing email, which meant that now users were getting flooded with emails. When they’d go to find these issues in Jira, they’d not exist. Word eventually filters back to him, and he shuts down the test.

So, what could we learn from this blunder? That’s simple. It is considered best practice to turn off email on any Development system you have. Don’t get me wrong; there will be times you need to test things related to email. When this happens, I turn email back on only long enough to run my test, then turn it immediately back off. It’s just not worth the user’s confusion.

And that’s it for this week!

What blunders have you made with your Jira instance? Have you any lessons learned you’d want to share? Then be sure to leave a comment on this post, and I might include it in a follow-up! And if you enjoyed this post, subscribe below to get new articles delivered right to your inbox!  You can also follow the blog on Facebook, LinkedIn, and Twitter to get the latest from us.

There are a few things I want to call your attention to this week. I want to start featuring interesting posts, webinars, or webpages I run across – and I have a few to share this week!

Let’s start with this blog post from Notes From Kris, which explains the various resources you have access to from Atlassian. Having all of these in one place is handy – especially if you are new to the Atlassian Ecosystem.

The next is a fun JQL quiz from Elements, which is an Atlassian Marketplace partner. I haven’t used any of their apps before, but they are definitely on my radar now. The JQL quiz was rather fun, but also very challenging. Give it a try and let me know what score you get!

And lastly, a webinar from Atlassian on “How to become an Atlassian Community Leader.” On top of my current goal to become an Atlassian Certified Master, I am also working towards a Community Leader status, so I plan on attending this webinar.

I hope you found something useful in this section. If you have, let me know, and I’ll keep including exciting things I see here! But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”

Book Review: 7 (non-user’s) stories on (not only) Jira governance

Rodney N.Leave a comment

Governance. If you are like me, this brings to mind long, boring meetings where you, as the admin, try to seek approval for some change, only to have the discussion quickly off the rails to something not even related to Jira. No, just me?  

I have long stood on the fact that I don’t know everything Jira. As much as I’m teaching others through this blog, I am still learning myself. And knowing my efforts at Jira governance have been less than successful, I was excited to see a new book on the way. I was even more excited to be offered a copy of “7 (non-user’s) stories on (not only) Jira governance” by P.J. Wysota to review! So, let’s take a look together with the first Book review of the blog!

As a note here, I did receive this book free of charge. Honestly, I was planning on reviewing the book even if I had to pay for it, so I don’t think I’ve let the fact it was given to me sway my opinion too much. But if that matters to you, now you know.

Summary

This book takes a rather holistic approach to the idea of Governance. Which is to say, it starts you out with some of the basics. As such, the first chapter’s theme was “Governance’s ‘Zen’ – keep balance.” Here, P.J. goes into detail about the balancing act that is being a Jira Admin, or “Solution Architect” as he prefers. And he nails it. The art of being a good Jira Admin is balancing competing interests. Your users want a fast, responsive system, but they also want every custom field and workflow under the sun.  

Another Story in the book that we had a lively discussion about on Twitter (especially after last week’s post) was about Getting the right people. While we don’t agree on terminology, I should point out that we at least agree on principle here. He prefers the idea of a “Solution Architect” – someone technically savvy enough to understand and manage the system, while being aware of how people are using Jira and what the teams need Jira to be. This person should be the core of a larger group of Jira Admins and a Sysadmin. While I’m not opposed to this idea – such people are at a premium in the workforce, so I’d instead work on building that competency yourself rather than finding someone to fill that role immediately. 

One of the stories I loved in this book centered around the concept of Strategic choices. I love this chapter because part of it argues, “Why and when not to use the Atlassian Stack.” It reminds me of something I heard a comedian say one time that stuck with me. This comedian said his father would often say, “If you can’t think of a counterpoint to your opinion… you’re not entitled to that opinion.” Or as P.J. put it:

And if you are to successfully govern Atlassian applications, pardon my French, but you need to strip off whole marketing bull***t of Atlassian, know pros and cons of your applications thoroughly, and be able to map any potential showstoppers in “Atlassian transformation” plan.

P.J. Wysota, 7 (non-user’s) stories on (not only) Jira governance

We, as Jira Admins, should know where all the pitfalls are. We should be able to go, “This tool may not be the best fit for this process.” However, P.J. goes into some detail about situations he’s been in where the answer wasn’t an Atlassian solution. And he raises a valid point here. If we aren’t empowered to say “Look, Jira’s great, but it’s not a good fit here.”, Jira will quickly get a reputation as a half baked solution.  

The Last Story in the book deals with the Atlassian Marketplace. This topic brought this blog to P.J.’s attention because it’s a topic I also covered recently in my “Jira Sucks” post. We both talk about this idea that some users have that Atlassian should put more core functionality into the product and lean less on the marketplace to fill these needs. 

We both approach the topic from different directions but arrive at the same conclusion – That Atlassian puts what they feel is needed by the majority of teams in their tools, and that any further needs can be met to fill those niche requirements. While the functionality may feel significant to you, they aren’t needed in a Project and Task management tool in the grand worldwide view.

And look – I just covered four of the Stories here. There are seven stories in total, and I took something I could apply to my practice from each one. When you have an infinitely configurable tool like Jira, finding a standard set of best practices is difficult. What works for one team may not apply to others. It’s up to you to figure out your teams’ needs and match up the specific capabilities to those needs. And that is the primary take away from the book. Governance isn’t about rules or processes, though they require those things. Governance is about figuring out the right setup for your organization in an inclusive way and requires you to build it into your processes from the ground up. 

Areas of Improvement

When I review Apps, I make it a point not to shy away from the bad points. If I can think of a way they can improve, I include it. And every App can be improved. I think the same should go for books. While I still wholly recommend the book, I feel I’d be amiss to my responsibility if I exclude this section. So, here we go.

I hesitate to bring this point up, though. As any long time readers can attest, I’ve always had my own struggles with editing. However, there are a few passages in the book I found myself reading a time or two to understand fully. They were always minor spelling, tense, or grammar mistakes – and trust me, I’ve published similar mistakes too – but it did interrupt my flow while reading.  

However, that was it. The ideas in the book were sound and well explained. I can see myself referring back to this book repeatedly to refresh myself on concepts as different situations come up. And I feel that is the real test of a book like this. It’s one thing to read it and understand the concepts. It’s another altogether to go back to it to apply those concepts at the appropriate time. And I feel this book hits that mark well.  

Would I recommend this book?

Yes, absolutely! As I started this piece saying, Governance is something I’ve always struggled with. And from what I’ve seen, I’m not alone. However, P.J. does a great job of breaking it down to reasonable Stories to apply to your Jira Administration practice. So if you can, take the time to read this book. You won’t regret it. 

However, that will be it for this week. If you’ve enjoyed this book review, don’t forget to like, share, and comment on it! I always enjoy reading your feedback! You can always find me on LinkedIn, Facebook, or Twitter, where I post the latest from the blog. If you’d like to get new posts automatically delivered to your email, don’t forget to subscribe below! But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

The Jira Dream Team.

Rodney N.1 Comment

So, I know I had said I’d have a book review this week. Unfortunately, it’s not ready. It’s like I’ve spoken to software teams forever now: A Bad product released on time is far more memorable than a Good product delayed. I want to make sure the review is worthy of the effort P.J. put into writing it. So, a delay is in order.

The second reason for the change is something I noticed late last week. This past Monday was the anniversary of the first post that went big. I had a few posts previously on here, but they weren’t consistent. Honestly, I was re-posting stuff I’ve done for work. But my post on using Jira for a job search – that had some legs and inspired me to start posting regularly. Seeing as that post was about me trying to get hired, I’ll take the opposite approach. I’ll look at who I would hire if I could build my perfect Atlassian team within a business. So, lets get started on this.

What Everyone Needs

We’ll start with the roles that every Atlassian team will need, whether they are supporting a software team, IT Team, or just general business teams. I fully realize that you’ll need additional people depending on your situation, but this is a good starting point. So let’s hop into it!

Team Lead/Product Manager

Every good team starts with a guy who can chart the path. I see this role as someone who will look ahead of where the team is going and remove roadblocks before the team arrives.  

Of course, to see these roadblocks, this person needs to be more than a little familiar with the tools and setup, which means it would help if this person were a former Systems or Jira guy themselves. Additionally, this role will need to interface with many people, so you don’t want someone here who isn’t good at managing these interactions.   

Ultimately, this person’s job is to look at everything that needs to be done and set the priorities. To do so successfully, they’ll need to balance a lot of different interests. They’ll need to take input from the team, stakeholders, vendors, and their research and experience, and make some tough decisions. These decisions won’t always make people happy, so they’ll also need some good conflict resolution skills. However, if you can get a superstar in this role, things will always seem to work out well for the team.

The Systems Guy

If I’m honest with myself, this is me. This role will ultimately be responsible for the backend health of Jira and Confluence. So, let’s talk about them.

This role should be familiar with running Java applications on the Server OS of your choice. Honestly, I learned to do this by running a Minecraft Server. Just saying, this isn’t the most challenging box to tick.

They should also be aware of how different front end changes can impact performance. This role will likely be your technical lead, so they’ll be expected to advise and review changes some of the other roles are making. 

Something you also want to look at is who will cover for who during PTO. In this case, the System Guy should be able to cover for the Team Lead or either of the Jira/Confluence guys should they need to take off. Ideally, I see the career progression here being Jira Guy -> Systems Guy -> Team Lead. This means that this role should be starting to develop those essential leadership skills. They aren’t ready to fly the plane solo, but they are definitely on their way there and can take over for short hops. 

The Jira & Confluence Guys

 This role manages Jira’s front end. While that is a simple statement, this will require a fair bit of specialized knowledge. This person will create and manage fields, work on workflows, and do all of the necessary things to configure Jira for the users. In fact, there should be enough work here to justify two of these people in any large organization.

In my mind, these people should be developing the necessary skills to start working on the system side. Ideally, they should be able to help out should the System Guy have to be out, but I wouldn’t expect them to be doing installs and upgrades solo just yet.  

This role will also be interfacing with end-users quite a bit – whether it’s capturing requirements for a proposed change or solving a user’s problems. So you’ll want someone good at asking “the right questions” to understand what’s going on. I’ve seen it time after time – what the user says they want and what they need is nowhere near the same. As the “expert,” it’s up to this role to guide users to what they need.

Customizing for your Org

So above are the people I’d say you need at the minimum. However, depending on what your organization is going, you might need some additional expertise. That’s where this section comes in. You might not need these people – but if you do, here they are.

The Developer

If I’m honest, I almost put this as an essential role. I’ve had one on the team before, and it’s incredible. Jira’s great about extensibility, but you won’t always find what you need in the Marketplace. That’s where having someone on staff who can write plugins to be a fantastic asset. 

This person should be familiar with the Atlassian SDK, as well as Java in general. Remember, though – once you go down this path, you will need to update these plugins with every upgrade. Custom plugins can also be a nightmare to deal with if you plan to migrate to the Atlassian Cloud in the future. For these reasons, I don’t ever recommend you go crazy with the custom plugins, and always look for Marketplace solutions first. 

This person can also take point on any Groovy scripts you use with Scriptrunner. This method is another excellent option to extend your Jira instance’s functionality without writing your plugins. It will still need updates now and again with upgrades, but it won’t be as bad as having a custom plugin to support. 

The Build Guy

So, you’d likely only find this in Software or DevOps organizations. However, if you are using Bitbucket and Bamboo, you’ll need one or two people to manage your build processes and systems. These should be people who are familiar with Build and Deployment pipelines and how to compile and deploy with your toolset. 

Honestly, this is one of my weaker points as an Atlassian Expert. I understand the basic concepts, but to scale it up to Enterprise level makes my head spin. However, I’ve been fortunate enough to work with some real superstars in this area who can even team a pleb like me something useful. 

This role won’t be needed for every deployment. For example, if you are only supporting IT and General business teams, there won’t be a need. However, I did want to mention it as if you need to support this kind of function; having a dedicated person is invaluable.

HelpDesk

So – this won’t be a part of your team. But if your organization has a dedicated helpdesk team, it would behoove you to empower them to help end-users with simple problems. That is, give them the access and documentation to update permissions and other problems users are likely to contact them for. That way, they can handle the day to day and let you focus on the larger, more complex tasks.  

The Helpdesk is also an excellent place to look for up-and-coming talent. Someone who takes som initiative and learns the Atlassian platform more might be a candidate should you need another Jira guy. It also lets them acquire the skills they need to better work with users to get the information they need to solve problems. 

And there you have it. The Jira Guy’s Dream team!

Honestly, in most organizations, I’ve performed multiple of these roles. But with the team I described, you should be able to handle almost anything that comes at you. But what do you think? Is there a role you consider essential that I missed?  

As always, don’t forget to like, comment, and share if you’ve enjoyed this content. You can find me on Twitter, Facebook, or LinkedIn to get the latest news from the blog. Please subscribe below to get new posts delivered every Wednesday to your mailbox if you have really enjoyed the post. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

Yes, Jira can be fun!

Rodney N.1 Comment

So, just saying, you guys loved last week’s article. It was a hit – and got the blog a new record for single-day page views.

That’s quiet the act to follow. However, I think it’s time we looked at the opposite end of the scale. Can Jira be used for fun? What are these fun use cases?

When we think of Jira, we often think work. Someone wants you to do something. Or there is something you are acknowledging needs to be done. However, I believe in the flexibility of the platform, so I’ve managed to find a couple of unusual use cases that prove Jira is not only for work.

Jeopardy, brought you by Jira

This one was brought to my attention by a colleague, but the original credit for the idea belongs to Dan Eads, who permitted me to share it. He came up with the idea for a Detroit AUG meeting. And let me just say, this is one of the best examples I’ve seen in a long time to prove Jira’s flexibility.

So, let me discuss how I set this up, based on the original Idea. My first step was to figure out my categories, and create a status for each one. I also took the time here to remove any extra statuses that wouldn’t be needed for this project. As a note, make sure this project is using a unique workflow that is not shared.

Note I use the “Allow all statuses to be transitioned to this one” option. This setting is more just to make my life easier, but it works well in this case.

Next, I needed to think about how to store the information. Each question will have three independent pieces of data tied to it: the dollar amount, the question, and the answer. Reusing as many fields as possible, I opted to have the summary hold the dollar amount, the Description contains the question, and a new field I called “Answer” to keep the answer. This new field was just a single-line text field, nothing to fancy.

You might ask, “Why I didn’t just put the answer into the description?” Well, I wanted to be able to click on the question in a Kanban board and have it display the question – to simulate how the problem is behind the dollar amount on Jeopardy. Having both the question and answer in the same field would then give away the answer. Hence the need to separate the two values.

Audience View

My thinking here is there will be two windows open for this – one that is displayed on a projector or shared on zoom for the audience, and a second hidden one for yourself. The Audience view will have the Kanban Board, but you will pull up the issue itself to see the question and answer in your view.

Your view

Now that we have the workflow and the fields, we need to work on the Kanban board. I started by going to the Columns and removing all the default options – replacing them with my categories. I mapped each Column with its appropriate status, leaving the backlog and Done statuses unmapped.

I also went into the Issue Detail View and removed all fields from there – that way, when I click on an issue, the audience can see the Description clearly and read the question for themselves.

And that’s it for the project configuration. All I need to do now is create issues to represent each of the thirty questions on a typical Jeopardy board. I found a good resource for getting questions quickly was https://jeopardyquestions.com. But feel free to think up your own company or ACE specific questions!

As a final note, I found the best way to clear questions that have been answered using my setup was to go to the Kanban Board while the issue was selected, click the ellipses, and then click “More Actions…” After that, click Done, which will cause the question to fall off the board and onto an unmapped status.

All told, writing up this how-to took me twice as long as actually setting it up. The first board, complete with the configuration from scratch and inputting all the questions, only took me about 30 minutes. I’d imagine each round after that would only take half as long to set up – especially if you already have the questions picked out.

This game sounds like an exciting way to use Jira to have a bit of fun, so this is something I suggest you check out sometime!

So a Jira Admin wants to do some writing

So question: you have a Jira Admin who wants to write a novel. How would they keep track of all the characters, stories, plot devices, etc. that goes into that?

Honestly, I’d use Trello. I use that to manage the blog, so I don’t forget post idea’s I’ve had!

However, a colleague named Jesse Wisener had the idea to use Jira and Insight to manage all these threads. Now, I am no-where near the Insight master that Jesse is, but I think I see where he’s going with this, so I’m going to try to do it justice. 

I’ll start by creating a new Empty Object Schema in Insight.

This gives me a rather large blank screen to work with. So now we need to start populating it! Click “Create Object Type” to start adding the broad categories. These will be things like Settings, Characters, Plot Devices, etc.

From here, we can branch out further, such as breaking up characters into “Protagonist,” “Antagonist,” “Extras,” etc. At this point, repeat for all the other categories as you write ideas down and need expansion. Is your protagonist exploring a new dungeon? Write the details down in a new entry under Settings. Do they find the one sword that will defeat the dark lord? That’s a plot device. This method is an easy way to keep these various elements organized.

Honestly, I’ve done something similar for a collaborative writing project I’ve been known to help with. I used Confluence spaces for each broad category, but it still is the same concept. This shared world we write in has been around for many years – long enough that some of the histories have drifted into “Lore,” but we still use Confluence to keep all these things in our collective memory, and it’s worked well for us so far.

And that’s it for this week!

I know this is a relatively short post. However, I’ve had a busy week, and I don’t see it slowing down just yet. However, many exciting things are lining up!

This Friday will be the first anniversary of my first post to get a lot of attention. Considering where I was last year – the change is fantastic. I’ve stated it before, but I was hoping a potential employer would read the blog back then. I consider this post the blog’s real start – as that is when I started posting regularly. To see how many of you read it every week now is more than I could have ever dreamed, so thank you. 

Second, Atlassian invited me this past week to look at some of the new ideas they have brewing for Jira Cloud. I cannot share any details yet (it’s very VERY hush-hush), but I am very excited about what they are doing. Honestly, I cannot wait to be able to share the news with you!

And finally, there is a new book on Jira Governance out. It’s called “7 (non-users) stories on (not only) Jira governance“, and I’ve gotten a copy to review. I’m only halfway through it, but I like what I’ve read so far. I’ve always dealt with governance because someone had to, but it’s never been a strong-suite of mine. So I’m looking forward to writing up the review for next week!  

If you’ve liked what you’ve read here, don’t forget to leave it a like, comment, and share on your social media of choice. You can find me on Twitter, Facebook, or LinkedIn with the latest from the blog. You can also use the form below to get new blog posts delivered directly to your inbox! But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

Jira Sucks, but it doesn’t have to

Rodney N.3 Comments

I’m betting you didn’t expect this title this week. Two things inspired this article. First, was this entry into the blog’s search performance.

This graph tells me that Google is returning my site when people are searching, “Jira sucks.” What’s more, people are clicking on the link. Not often, but still!  

The second event that inspired this post is another post someone did on LinkedIn explaining why they feel Jira is simply the worst. The odd thing is, every point they brought up is something a good Jira Admin can fix.  So I figured I’d look at why using Jira can be a terrible experience and how you can fix it for your users.

Also, a bit of a confession: usually, I like to have these articles ready by Tuesday before publishing AT THE LATEST. However, by that time, I didn’t have enough talking points to make a full article. So I had to go to social media to get feedback from the broader community! Thankfully you all gave me enough to round out the post. So, let’s get into the first of Jira’s sins.

“Jira makes it challenging to create an issue.”

I’ve seen this on almost every new instance I’ve worked on as a new Admin. The issue creation process is so arduous that most workers would rather not deal with it entirely. This experience often leads to the feeling that Jira as a whole sucks, because people don’t understand that that experience is unique to their instance. Let’s go into three factors that can lead to this experience, and what you can do about it.

Required Fields

This item is usually the biggest offender. For one reason or another, you will have a large number of required fields, which may be spread out between several tabs on the Issue Creation Screen. This format makes it so that your users have to play “Hide and Go Seek” with these required fields, click save, realize they missed one, and repeat. I’m hoping you can see how this can be frustrating to users.

I take two approaches to combat this. First, I limit the number of required fields. I do this by being diligent in asking “Why?” every time a project lead asks me to make a field required. I make sure their reasoning is sound, and that they intend to use it in some meaningful way. I also educate them about the fact that if they have too many required fields, people are going to put in junk information to get past the screen, making whatever report or information they derive from it useless. 

The second approach here is to put all the required fields front and center. That is, I put them all on the first tab, right at the very top. That way, users can tell what fields they need to fill out right away and get on with their lives. It just leads to a cleaner look overall, so it’s something I always recommend.

Too Many Fields

This one also causes a ton of headaches. People see they can customize their Jira with custom fields, and go a bit crazy. Doing so leads to a bloated, unfriendly look to Jira.  

I mean, imagine it. You are a user, and all you are trying to do is create a task to track some work you are doing. However, when you click “Create,” you are hit with a wall of empty fields to fill out. What’s your likely response? To fill it out, or say, “Eff this!” and do the work without the Jira issue?  

So, how do we combat this? Well, we always have to be diligent when creating new fields. Again, I remind you that the question “Why?” is your best friend. Find out the reason the project leads need a field. Do they want to use that information in a Dashboard? Or is it something they will need to help prioritize work? Or is it some vanity information that can live just as well in the issue description? Don’t be afraid to say “No” if the answer to that last question is “Yes.” Not only will this help with Jira’s appearance, but it will help your instance run smoother!

Secondly, we can organize the fields that we do have. Maybe only specific teams will need any subset of fields. Then we should set up tabs on the screens, which each tab representing each team. Or perhaps you only need a particular set of fields when you go to a specific status. You can have them pop up when a user transitions the issue into that status, so they don’t bloat the creation screen. The point is you have tools to organize fields, use them!

I can’t find my work in Jira.

This reason is another one I see a lot. People who aren’t familiar with Jira may find it hard to figure out how it’s organized, or where their work even is. That will lead to the opinion Jira is just too complicated and bloated. So how do we combat this?

Well, first things first – we have to talk about your system dashboard. This feature will be people’s first experience with Jira after logging in. So you will want to make sure it’s a welcoming one. Customize the introduction gadget to point to your documentation (we’ll get to that in a moment). Be sure that the “Assigned to Me” gadget is in place. However, if a user is genuinely new, they won’t have any issues assigned to them, so keep that in mind when designing your System Dashboard.  

Back to the documentation, you’ll want that in place. Jira hides its search functionality in a dropdown. Be sure people can readily find the documents to help them learn to use it. Searching issue data is Jira’s superpower, so you want to get people up to speed with that quickly. Also have documents about setting up dashboards available, and make sure people know they can create a custom dashboard to help them find their work.

And finally: workshops. As a Jira Admin, I try to hold regular seminars on JQL, creating Dashboards, tips and tricks with queries, and best practices. Some of these workshops I turned into the early posts on this blog! Be an active part of training your userbase in Jira. It will help combat the feeling that people can’t find their work.

I always have to buy an add-on to do simple tasks!

Oh boy. This one is a big complaint. And I get it: Apps are expensive. I’ve had to explain to more than a few Atlassian Partners that when I do a review, I have to get a trial license because I can’t afford to be buying (or renewing) an App a week. And if they restrict their trial license, that means I can’t do a full review.

Unfortunately, this one comes down to economics. How many employees do you think Atlassian has? The number will surprise you considering how big they are in the market, but the most recent figure I can find put them at around 3600 employees. And that’s everybody, from Custodial on up to the Founders.  

Let’s be generous and say a quarter of that number are software engineers. I have no backing for that number, but it’s an assumption, so bear with me. That means that 900 Developers are working on everything Atlassian has. Trello, Bitbucket, Confluence, everything. I counted about 20 different products offered from about the timeframe we are looking at. That means we have an average of 45 Developers per project. Now, I admit some products will have more developers than others. That’s not my point.

My point in all this is that there are only so many person-hours that can be put into features. As much as Jira wants to be the be-everything-do-everything, that takes time that they simply don’t have. So, what do you do? 

Their solution to this problem is well tested. Create an API that others can use, and allow an Add-on economy to develop. That way, Atlassian can focus on features that a larger group of people can use, and let App Partners develop more niche solutions. However, these Partners need to be able to feed their families. Some have whole businesses to support, which is why they tend to charge what they do. 

Jira sends to many emails!

My god, does Jira send out some emails! I’m sure every Jira Admin can sympathize with their users on this one. This one is objectively fact-worthy. 

The first thing I do here with a user like this is commiserate with them. I let them know that I interact with multiple projects each day, so I’ll get even more emails than they do from Jira. Acknowledge that they have a legit complaint.

Then I share with them how I manage it. I let them know how I go through, find all the issues I’m “watching,” and I unwatch any that are no longer relevant. This “fix” won’t help with current issues spamming you, but it does make a dent. I also show them how I sort Jira issues in Outlook so that I don’t miss anything critical, but am not bothered by an email every day.  

And finally, I let them know there is hope. Atlassian has announced during their last Summit that they will be implementing a feature to send out an email Digest of several updates, rather than a single email with each update. I cannot tell you how much I want this feature right now. This tidbit was honestly one of the happiest pieces of news from Summit.

And that’s it for this week!

Look, the point is your user’s experience – and thus, their outlook on Jira – is entirely in your hands. Always keep in mind that people use your system. Whenever you implement something, the question should be, “How will it impact the users?”

Honestly, I still have enough points for a followup article! You guys helped out a lot. But as I stated, I’m already running late enough on this post, so I think I’ll call it here. If you enjoyed this article, be sure to sign up below to get new posts delivered directly to your inbox! You can also follow me on Twitter, Facebook, and LinkedIn to get the latest news from the blog! Don’t forget to like, comment, and share the posts with your friends! But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”