The Perils of Marketplace Apps and Heavy Jira Customization – Advice from Atlassian and Steve

Posted by Steve Elliott on May 30, 2018 2:27:09 PM

Atlassian recently released a terrific, yet cautionary, article and infographic on strategic ways to prepare for scaling Jira to the enterprise. They shared some pretty mind-boggling statistics on the size and scale of their enterprise-sized customers’ Jira instances. As a Jira fan, my eyebrows raised so high they nearly left my head when I read the statistics around the sheer scale of what enterprises are doing with Jira at the team level:

  • Enterprise Jira customers create 900 custom fields on the average - the largest number of custom fields for one customer is 4,800!

  • Large Jira customers have an average of 1200 projects, with the highest number of projects for a single customer coming in at a whopping 4200! And, the number of Jira projects increases annually by 17%.
  • On the average, Atlassian’s largest customers have on the average of 400 custom workflows. The highest number of workflows in a single instance is 1400!

  • The average number of issues managed for large Jira customers is 1.4 million, and issues tracked grow on the average by 23% per year.

The kicker to the whole thing was a statistic that should grab everyone’s attention: to tailor Jira to their use case in attempting to scale, their largest customers configure, integrate, and maintain an average of 23 Atlassian marketplace apps. Keep in mind that these apps are not Atlassian products – they are all separately developed, supported and licensed by different companies!

Imagine all of those interactions happening simultaneously, just at the team level: when an enterprise organization sets out to scale their Jira teams, what kind of planning, preparation and maintenance must it take to get 1.4 million issues moved around inside 400 different workflows using 900 custom fields integrating with 23 apps?

Think about the level of effort it would take to support that much customization in enterprise organization. The massive scope of taking all those moving parts in such a flexible system and the maintenance required to keep them working smoothly together, all while keeping the people using them happy and productive while the Jira user base increases constantly is no small feat.

So, it makes sense that Atlassian would issue a set of precautionary recommendations for strategically configuring Jira at enterprise level scale. In a nutshell, these are:

  • Project end user adoption several quarters into the future and plan for it

  • Too many custom fields can lead to scaling challenges in maintenance and compatibility

  • Dependent projects need to coordinate and design their workflows together

  • If an existing workflow can be used by multiple teams, opt to repurpose it

  • Keep apps down to a manageable number and ensure compatibility between them

The theme here is clear: if you need to scale with Jira, simplicity and cross team coordination is not only key, but absolutely critical to success.  At AgileCraft, most of our customers use Jira at the team level in concert with our platform for connecting to the portfolio and program levels. Consistently, the have told us that if you decide to implement many Jira apps, multiple workflows, and too many custom fields, they will inevitably crash into each other and slow down the system when you try to work at scale. This leads to plenty of unplanned labor in order to continually get them untangled and configured properly. 

Here’s the conundrum: With a platform as powerful and flexible as Jira, why would an organization decide to configure it in an unsustainable way? The answer is organizations do not systematically or even intentionally deploy hundreds of custom fields and dozens of apps.  This challenge emerges over time as hundreds of isolated decisions create a hairball of complexity.

Atlassian knows their product and customers better than anyone, and I strongly encourage every leader of a Jira team to take their advice to heart. Executing on these recommendations requires work, thought and time to plan. So, consider that AgileCraft creates a seamless connection of Jira teams to the portfolio by delivering these key benefits, without the hassle of maintaining so many apps:                                                                             

  • Scale instantly – easily add a few or a lot of teams or trains at any time, without any hassle.
  • Teams can use whatever workflow they choose without impacting other teams or worrying about information not getting to the program and portfolio layers.
  • The disparity in terminology of custom fields becomes unified, creating cohesion at the program and portfolio level.
  • Sophisticated dependency mapping allows teams to know who their work impacts and makes coordination simple and easy.
  • Use a single platform instead of piling on a bunch of disparate marketplace apps, reducing maintenance and training.

On the Marketplace app topic: I’ve written about this before, and I’ll spare you all the full soapbox in this post, but I have to just get this point out there again through the lens of the statistics that Atlassian just published, because it’s pretty astonishing:

     If you have an enterprise with 1.4 million issues moved around inside 400 different workflows using 900 custom fields, when you add 23 integrated apps on top of that, it can only spell disaster in terms of increased costs, wasted time, and lowered productivity. Why would you want to go through that complicated configuration and maintenance nightmare when you could use AgileCraft to bring all your workflows and issues together, integrating them seamlessly, and instantly uniting the team level all the way up to the program and portfolio layers?

We often get the question of total cost of ownership: sure, Marketplace apps are cheap on the surface when just considering the cost of a license. But, there are hidden costs that become exponentially complex when you factor in time spent dealing with multiple vendors/licenses/support teams, complicated configuration, management, and integration testing as well as acquiring resources, testing, and training. AgileCraft eliminates those factors entirely, allowing everyone at all levels to focus on the most important thing: getting actual work done.

Atlassian did a great job at spelling out the precise challenges that Jira users will encounter as they start their agile scaling adventure – this advice is worth its weight in gold. AgileCraft was created to address those challenges, and takes the pain out of managing your agile software lifecycle. It connects the critical work at the team level to the strategic work being done in the portfolio with ease.

Come visit us at agilecraft.com to learn more about how AgileCraft fits perfectly in the gap between Jira and the portfolio level. 

Topics: Scaled Agile, Enterprise Scaled Agile, Digital transformation, Agile, atlassian, JIRA, CIO, enterprise agile, agile at scale, strategy