Following on from my last post about the benefits of objectivity (e.g. that Blended is a purely neutral consultancy) I thought I would focus in on some key tips for helping you decide on which of the almost thousands of apps you might use.
It’s a six step process:
1. Look at your app portfolio by foundation product
2. Identify candidate apps
3. Build a picture of the process to be supported
4. Systematically select the best candidate
5. Pilot “quietly”
6. Train, train , train
1. Look at your app portfolio by foundation product
What this means is that you should create a matrix which captures the functions you want to support with the candidate apps available.
Here is a basic example:
| Function | Core App | App 1 | App 2 | App 3 |
|---|---|---|---|---|
| Agile | Jira Software | |||
| Scaled Agile | Jira | Big Picture | Portfolio | |
| Waterfall | Jira | Software Plant Big Picture | Structure | Traffic Lights |
| Time Management | Jira | Tempo | ||
| Jira Service Management | Jira Service Management | Deviniti Extensions | ||
| Asset Management | Jira | Riada Insight | ||
| Document Management | Confluence | Comalatec Workflows | ||
| Testing | Jira | Xray |
The good news is that we have standard functional matrices which you can use to speed up your assessment process. The categories that Atlassian has on its marketplace are too large and so we have broken them down into a finer view. If you have too many overlapping apps you may be spending too much, or confusing users as to what to use.
The ideal is a clear functional segmentation with the best possible app in each area. It is important to note that certain perceived functional areas don’t necessarily need an app. For example if an app is simply creating a new issue type such as “risk” with a new workflow – we regard this as being better supported, native in Jira.
2. Identify candidate apps
Once you have identified that you want to select an app – don’t just pilot the first interesting looking candidate. Sometimes when this happens a pilot is started and there is no going back even if many teams don’t like the product.
The current Atlassian categories are found in the attached image and as can be seen there is a huge overlap. ⇒
An initial screening method can be to start with the most successful app by the number of downloads per app in the segment. We feel three is a good starting point. If you were to look at the “draw” segment – e.g. a Visio or Powerpoint replacement tool; Draw IO, Gliffy and Lucid Charts would be your best candidates.
Yet the Atlassian category has 227 candidates. That’s because they have collapsed charts and diagramming into the same category. Really it’s just diagramming. Also the foundation app would be Confluence most likely.
3. Build a picture of the process to be supported
In the testing segment for example we mapped out in our analysis what the end goal of doing all testing in Jira was, and some of the key outcomes. To speed this up – app vendors also have documentation laying out the processes they are supporting.
Here is a sample of what we mean below.
4. Systematically select the best candidate
If you have a staging environment or a partner with such a facility – download the apps on trial so that your assessment can be a real one.
We recommend a systematic review taking into account the following major characteristics;
- What does the app do that is new or more complicated than Jira or Confluence? How does it rate in terms of functional richness?
- How well does the app leverage all the inherent features of Jira or Confluence? remember these are the foundation reporting and collaboration tools – the app isn’t working in isolation
We call this the 3rd Party Ap excellence matrix or Apex for short. Our testing case study is here A Round Up of Third Party Testing Apps for Jira Server – What’s the Secret Sauce for selecting the right solution for you?
In the end not everyone will want the Rolls Royce solution and not everyone will weight the same characteristics that we recommend. Even harder is that each vendor is rolling out new features continuously – its not at all a static picture. The best thing to do is conduct quick, systematic analysis, make a decision and get your teams productive.
5. Pilot “quietly”
Ensure that you have representative teams checking out the functionality – after its passed muster in staging we really recommend that the app is made available to only a small number of teams for real, essentially production level, acceptance. These apps are designed out of the box to be extensions to the core products and are really “upgrades” to base Atlassian functionality – speed is the key. Use retro based feedback approaches with real teams to ensure the app is working for you on even a weekly basis to ensure success. Naturally work with a partner like ourselves to ensure success – there is no need to go it alone.
6. Train, train , train
Some of the 3rd party apps offer significant new functionality and won’t be as effectively adopted without proper training. Make the effort and set aside the budget, it pays dividends.This can be achieved by webinars, self help training and resources from the vendor as well as workshop training. We have seen frustration from teams, simply because they adopt an app and can’t get past the simplest of problems only to discover that it was always an easy fix or configuration change.
Summary
This post is really designed to demonstrate that 3rd party app selection should be strategic, selective, tested and deployed all as quickly as possible to ensure that your teams are able to leverage the power of the Atlassian toolkit. Once you have some successful teams make sure you advertise their success to your broader user base to encourage adoption.
Naturally we can help you with your journey. To restrict 3rd party apps, without good reason, when there are so many available seems a shame and will constrain your team’s productivity with the tools – what is more important is that you select the right 3rd party app for you.