Weird setups that push your Atlassian products to the limit

[Paz]

One of the wonderful things about Atlassian products are their extensibility and flexibility. And sometimes those traits can lead to some, shall we say interesting challenges you may face on a regular basis. 

For example:

• Jira doesn't do time tracking how your org does it? There's an app for that. Actually, there's an app for everything... and you have installed them all.
• Your company has an atypical reason for needing hundreds of Confluence spaces. 
• Do you have thousands of users? Or tens of thousands of issues? Is your scale epic?
• Or maybe you installed so many integrations that you're not even sure where Jira Service Desk ends and a third-party app begins.

No matter what your wonky configuration is, I want to hear about:

• your weird and whacky setup, and why it works for you, or why it doesn't - the weirder, the better!
• your extreme customization of an Atlassian tool- wild and crazy color schemes and workflows are encouraged!
• your hard-to-fathom scale at which you're using an Atlassian tool.
• your reliance on an enormous number of integrations or add-ons - if your company had to build it in-house, and it's become mission critical since, even better!

The point is, when all you have is a hammer, everything starts to look like a nail. But when you have a Swiss army knife you feel like there's no problem you can't solve! Even if you end up using the can opener to pry open a bottle of wine while you're camping ;-)

So please, share your weird setup, and let's see if we can't learn something from each other!

[P_D_ Foerster]

That's a great idea! Like it :)

I'm also excited to hear about other people's crazy setup :D Is there anyone from LinkedIn? If I can remember correctly, they have a huge Jira instance with over ten million issues. If that's not crazy I don't know :D

Unfortunately, I cannot contribute because our setup of Jira, Confluence and Crucible is rather normal and medium-sized I think. We running all three applications on the same virtual machine including a local database. Over the next weeks we want to separate the database.

We do, however, have a crazy workflow for changes in our support projects but I heard that we will create a new one because the current is too complex

[Paz]

Don't hold out on us! Let's see a screenshot of that crazy workflow!

[Divakar Ungatla]

We created a CUI chatbot framework called BenTen and open sourced it recently. This has  out of the box slack bot support for Jira (along with other integrations like Jenkins etc..) with a conversational Interface. Eg : you can type `create a jira story` and it will start asking the necessary questions and then go and create a story in Jira and many more (https://github.com/intuit/benten#features) 

Also it has ability to compute metrics like cycle time when you say Cycle time over the last 3 sprints and present it in a nice png format inline in slack. 

Below is the link to the code repo. 

https://github.com/intuit/benten

You can actually try out the bot by joining BenTen workspace in slack (Try it out!)

The bot here runs against mock Jira server built using Karate test doubles

We use BenTen it in our organization (Intuit) to create stories/issues from slack bot, to log hours in during scrum, to get cycle time and velocity reports in sprint retrospectives and trigger Jenkins jobs .

And of course it is super easy to set up BenTen (10-15 mins) and even lesser time to add a new feature.

Do try it out!

[Paz]

Holy cow! This is incredible...

First, I love the imagery conjured with the name BenTen. I don't know if it was intentional, but my son used to be huge into the Ben10 cartoons not long ago. They were great!

Goodness, the second part about this is... EVERYTHING?!?! 

I will have to carve out some time to set this up when I get back from holiday.

Thanks so much for sharing this @Divakar Ungatla! It's wonderful.

[Divakar Ungatla]

@Paz Thanks! Please do try it out. Love to hear your feedback on this!

[Brian Hill]

Heh, nice call-out, will make for interesting reading. I've got a customer who've implemented a custom UI in JIRA, sitting at well over 6m issues now, been running JIRA as a full stack BPM for core elements of their business. I had to build a fast proof of concept for supporting a 50% increase in agency output at one point, so we modelled the key artefacts into a complex 34 step workflow for the parent issue, with triggers off into multiple child subtasks with (not quite as) complex workflows of their own. Was a fun piece of work.

[Paz]

WHAT!?! THIS IS CRAAZZY!

How long did it take to do all this work you're describing @Brian Hill?

[Brian Hill]

Like many customer stories, it started out with JIRA as an issues manager for project delivery management, and built out from there, incrementally.

The power of OS-workflow sparked our curiosity for going further, so started with 1 system integration and kept going from there. We're talking a multi-year investment.

System's been running for over a decade, so we've lived through (endured) multiple Atlassian UI changes, hence the desire to quarantine the impact of that with an in-house UI that saved us from constant documentation set re-writes.

Crazy? Not really. It was a structured investment decision, based on getting maximum value out of tool investments, rather than falling prey to vendor/platform churn. All of this pre-dated JIRA core and we kept Atlassian informed of how useful it was as a BPM.

[Paz]

Well good on you for trying to be innovative. I'm going to share your story with some of the design team internally, as I think the pain you've felt is important for us to keep in mind when making decisions. It always helps to have a real story from an actual customer to remind us what's at stake.

Thanks for sharing! I look forward to an article or write-up of some sort with some screenshots so I can see this thing you've built. I'm super curious now...