In This Episode
In this three-part mini-series, we talk about how to evaluate plugins.
This episode focuses on the following products:
- All products.
This episode is hosted, produced, and music by Mark W.
All thoughts, comments, tips, and best practices shared by the host and or guests of the Admins of Atlassian Podcast do not reflect the views of Atlassian nor do they replace procedures and steps officially provided in the Atlassian product documentation.
You’re working away and a user reaches out to you and asks “Can JIRA do this?” or “I found this plugin to do this for Confluence. Can we install?”
You go to Google, Atlassian Answers, or the Atlassian Marketplace to see if there is anything that matches the request of your user. And as you peruse the list of plugins available for your application, overwhelmed at all the amazing choices you have before you, you stop and ask yourself “Which one do I install?”
In this 3 part mini-series, we are going to talk about plugins aka add-ons. We will discuss verified plugins, what they are, what to look for when evaluating plugins, and what you can do if you don’t find what you’re looking for. All this and more on Admins of Atlassian, I am your host Mark Williams and coming up first in this plugin mini-series “Choosing your plugins and what to look for”.
When I first started out managing Confluence and JIRA, I did what admins normally do, I found a plugin and installed it to Prod. I didn’t realize at the time that I was creating this view that all you had to do was ask, and I would install any plugin you requested.
When listening to other admins at Atlassian Summit and Atlassian User Groups, everyone was doing the same. And this practice, which is so common in new installations, soon find itself coming to a halt as the system matures.
So, what do you do when you find yourself tightening control over what plugins to install? And if you are new and have yet to install your first plugin, then this is the episode for you.
After getting experience under my belt, whenever a user requests a plugin I counter with a question of my own “What are your requirements?”
Now, this is a loaded question depending on your experience with JIRA, Confluence, or the Atlassian suite. Asking for the requirements, you are asking the user about what they want the application to do. From the user’s response, I move the request into two buckets – the first being application training and the second is further analysis.
Why application training? Often times I would receive requests and it was functionality that the application already had. I then used this opportunity to bolster documentation and share functionality with users. This was also empowering to users as they learned something new, learned the application better, and was able to continue on without any roadblocks.
For those that were not training moments, they fell into the further analysis bucket. This is where I would gather more detail on what the user was trying to do and what they expected the application to do. Based on the user’s response, we could move on to identifying a plugin to evaluate. For those that didn’t progress to a plugin, evaluation became identified as a process replacer.
What is a process replacer? The second type of add-on requests was to try to fix a process or add a Band-Aid to a broken process. What I mean here is that a plugin is being requested to do something for the sake of doing it or because it has always been done that way. When I would migrate teams from other tools or non-existing tools to JIRA, I would get requests for plugins or requirements that JIRA had to do X. When I would ask why the answer was “because we’ve always done it this way”. If you dig deep enough, you will find that some processes are developed from a lack of functionality in another tool. For these users, I would tell them “You have a blank slate. You can make things simpler and easier. Let’s use it out of the box and then chat about what you believe is missing.” For some, it reverted back to training. Using the application out of the box satisfied their needs. The hands-on experience eliminated the perceived need for extra. For others, their requests morphed into something wildly different and mostly involved custom workflows as opposed to a custom add-on.
For those that didn’t fit in either category of application training or process replacer, we then pulled up our sleeves and began our plugin evaluation.
What’s in a plugin evaluation? The easy answer? Whatever you require. To help get you started, here is what I did for plugin evaluations.
First, requirements. We have to go back to the requirements. After the user’s request passes my sniff test I would create a Confluence page, for documentation, and a JIRA issue to track the work for doing the evaluation. At this step I would also cross compare other add-on requests to see if any of the requirements were the same if so, I would link the issues together and if an evaluation was performed, I would investigate our results.
Marketplace & Community
Next was the marketplace and Atlassian Answers (Community) search. I would look at the requirements and make a list of plugins that had that functionality. Once the list was compiled, I would take notes about each plugin. I would notate:
- Who was the developer?
- When did the development company start?
- When was the plugin first introduced?
- When was the last update?
- How often does the vendor update?
- What is their support like?
- What is their documentation like?
- What are the plugin reviews?
- What are the known outstanding issues of the plugin?
- Is it an Atlassian Verified plugin?
This information helped me understand how long the plugin has been on the market, if the documentation is good, what users think, and how well it is supported. These were questions I developed over time as my user base in JIRA and Confluence grew. One bad plugin could make 4k people unhappy.
Scheduling & Testing
The next step was scheduling time to install each plugin on the Test platform for review. Once I defined the schedule, I would send this out to the person(s) that requested the plugin, along with JIRA Project Administrators or Confluence Space Admins. Why? These Admins were my first line of defense, and they knew their teams. It may have been possible that their team could have been struggling and just maybe, this plugin could help them out. So we made it a requirement to include our Admins in this type of activity.
After the schedule has been built and shared, on install day, I would load the add-on to a development platform. I would spend 1 week testing the plugin from every aspect I could, along with basic JIRA or Confluence functionality. I would try to break it. I would compare the plugins features to that of my requirements and check off any that were met spot on and make notes of those that were close. After my testing was done, I would then look back over the plugin and make note of any changes to the UI. New menu’s, or drop-downs. This step was important as it determined HOW we would communicate to our users before they started asking “What’s this thing here? I’ve never seen it before.”.
After the shakedown on the development platform was complete, I would promote it to the Test platform and then reach out to those that requested the plugin and our Admins for testing. The testers would add their feedback to a Confluence page about what they liked, didn’t like, and if it met their requirements or not.
This process would be repeated for each plugin and the users would rank which plugin they liked better, and which was the easiest to use. Based on this feedback, along with all other gathered facts, my team would render a decision to purchase or pass.
It may seem like a bit much to simply pick and install a plugin, but I believe it really helps in understanding WHAT the users are trying to accomplish and to review all the offerings that is available to me. I believe that user feedback is essential for adoption and if my users agree that are particular plugin is easy to use, and satisfies their requirements, then they will be much better off and much more productive in their day-to-day.
That’s it for this first part of the plugin mini-series. In part two, we talk about Atlassian Verified Plugins and what they are.
Be sure to check out the release notes for this episode on AdminsofAtlassian.com for links to anything that I’ve discussed in this episode.
If you are new to Admins of Atlassian podcast, be sure to check out our previous episodes and if you enjoyed this episode, be sure to subscribe on iTunes (Apple Podcasts), Google Play Music, or through your favorite podcast app.
Thanks for listening, cheers.