Is Jira going full team isolation mode for boards?

[Jimi Wikman]

First we got Roadmaps that can't handle data from other Jira projects, making them useless for multi project boards and now I discovered that we no longer can filter in data from other projects using custom fields because Sprint management no longer will work.

Being able to cross collaborate, especially with integrations and incidents, have always been an important part of any Jira setup I have seen and now it seems Atlassian is moving away from allowing data to reside in multiple projects in favor of fully isolated containers.

My question is why is it even possible to have boards with data from multiple projects if the boards stop working if you do?

I feel that this is taking Jira in the completely wrong direction where the system promote fragmentation of work processes at the expense of strategic aspects of the companies. The whole team based project thinking seem to make Jira worse and not better and after 11 years and countless disappointments like removing resource management in Advanced Roadmaps, I am seriously considering leaving Atlassian's products in favor of more modern solutions that are not focusing on the old and defunct Agile way of working.

Am I the only one feeling this way and missing the old days when boards actually were able to handle all data in your filter and where new products were not just MVP's that were almost unusable in a practical sense?

Jira used to be great...Not sure what it is now.

[Nic Brough -Adaptavist-]

Company managed projects are not going away.  A lot of us restrict or even disable the ability to create team-managed projects.

[Jimi Wikman]

@nicI know. This is happening in company managed teams.

I agree that any serious company that have collaboration between teams, will disable the team based projects.

I forgot that we also get unique views in the screens as well using layouts, which also cause confusion.

Things are getting messy for controlled setups.

[Nic Brough -Adaptavist-]

Ok, so you'll need to get your administrators to work together on standardising your projects and not letting people diverge away from the standards.

[Jimi Wikman]

The problem is not the people, it is that company managed projects are overridden by boards and that data no longer can flow between multiple projects.

I can have people agree on the same setup using team managed setups as well, but the purpose of a company managed project setup is to not have to rely on people to do the right thing...

[Nic Brough -Adaptavist-]

Eh?  I'm sorry, I do not understand any of that.

"company managed projects are overridden by boards"?   What?  What does that mean?  What is being overridden?  

"data no longer can flow between multiple projects" - what data flow has stopped?  Where?  What is stopping the data flow?

[Jimi Wikman]

Every project can override the view of the issues, for example. So while you define what fields each JIRA project have access to globally, each Jira project admin can alter their placement and even hide fields if they so choose.

Each board can choose estimation type, which is one of the things you really want to control.

Components are still project based, even in company managed projects.

Roadmaps do not work with data from more than one project.

You can not add issues based on a custom field from other projects into a board unless you specifically add a project to each query. If you do, then you must add a global permission to allow anyone to manage sprints, and you must do that in all permission schemas or your scrum board become unusable.

So, two of four features for boards do not work if you extend your board outside the Jira project.

Company managed projects do not control issue view, estimation or components.

[Nic Brough -Adaptavist-]

>Every project can override the view of the issues,

I'm sorry, I still don't understand what you mean with "override".  Every project has settings that determine how the project works.  That's the point of projects - a collection of issues that have something in common, including a view.

>So while you define what fields each JIRA project have access to globally, each Jira project admin can alter their placement and even hide fields if they so choose.

Only in team-managed projects if you choose to allow it.  Company-managed projects can inflict whatever the admins choose to on a team.

>Each board can choose estimation type, which is one of the things you really want to control.

Yup, that's flexibility.  When you choose to scale up, you have to remember that a massive part of that is getting every team to agree to work the same way.  The software is just giving you flexibility.

>Components are still project based, even in company managed projects.

Yep, that's because different teams may see them differently.  If you need global fixed lists, use a custom field.  

 > Roadmaps do not work with data from more than one project.

Roadmaps don't work with team-managed projects yet, but it's near the top of the list.  In the mean time, use company-managed projects when you need company-wide roadmaps

>You can not add issues based on a custom field from other projects into a board unless you specifically add a project to each query.

Nonsense.  A lot of places I work with regularly have board queries that are "Project = X or label = team-x"

>If you do, then you must add a global permission to allow anyone to manage sprints, and you must do that in all permission schemas or your scrum board become unusable.

 Yes, that is a downside, but it does force you to actually work together.

[Jimi Wikman]

I take it you have not seen the new issue view?

https://support.atlassian.com/jira-work-management/docs/what-is-the-new-jira-issue-view/

"Don’t like where a certain field is placed? No worries: your team has control over where fields live! "

"Roadmaps don't work with team-managed projects yet, but it's near the top of the list. In the mean time, use company-managed projects when you need company-wide roadmaps"

I don't care about team managed projects. This is the situation for Company managed projects. Adding content from another JIRA project disable the roadmap.

"Nonsense. A lot of places I work with regularly have board queries that are "Project = X or label = team-x""

I have done so as well for well over a decade, but now it does not work anymore as it is classed as a complex query if it lacks project:
https://support.atlassian.com/jira-cloud-administration/docs/use-manage-sprints-permission-for-advanced-cases/

Try to add a board with project issues and any issue that have a custom field value. It will instantly shut down the manage sprint function unless you globally allow anyone in any project to manage sprints in that project.

--

So, what I am getting at is that "Company managed" is not really company managed, but still have aspects that the Jira Project Admins can override or have completely specialized for their project without any way to manage that at a company level.

I also think that disabling functions because issues pass a project barrier is counterproductive for collaboration.

Just my two cents.

[Nic Brough -Adaptavist-]

>I take it you have not seen the new issue view?

Been working with it since it arrived.   Heck, I saw it before it went out to customers in general (and gave some feedback on the prototype, a lot of which was ignored)

So what if a team can re-arrange their view of an issue?  What's the problem with that?  That's how they choose to work.  If you force a clunky view on a team that doesn't work for them, they're going to ignore you and work around it anyway, so, well, don't do that.

>Adding content from another JIRA project disable the roadmap.

I think you have some very poorly configured roadmaps.  The roadmaps I'm using don't get disabled

>Try to add a board with project issues and any issue that have a custom field value. It will instantly shut down the manage sprint function unless you globally allow anyone in any project to manage sprints in that project.

Yes, I said that was a problem already, but note that it is only for a problem for teams that don't trust each other, and it's a consequence of the flexibility that Jira has from trying to support non-Agile processes in its early life.

However, I really do think you've summarised what we've been talking about absolutely superbly with this paragraph:

> So, what I am getting at is that "Company managed" is not really company managed, but still have aspects that the Jira Project Admins can override or have completely specialized for their project without any way to manage that at a company level.

You're spot on.  The way I want to contextualise it for Jira is that Atlassian have a problem with what Jira is actually for and how it supports lots of different ways that people might want to use it.

I am vastly over-simplifying this (I'm an engineer, trained to be a reductionist in my thinking), but I think of this as a simple scale. 

At one end of the scale, you've got determinism and micro-management - everyone does everything exactly the same way.  You can plan to perfection, and calculate every goal and target because you know exactly what is going to be done and how.

At the other end, you're totally Agile, with teams working in any way they feel works, ending up with delivered stuff that meets the goals at the time you need them, despite the fact that they've shifted while you've been working, so you still manage to deliver something that people want, rather than what they asked for a couple of years back.

Jira has an internal fight going on - it wants to support people across the entire scale at the same time.  But you can't run a self-organising (agile) team with micro-managment.  So Jira tries to cover as wide a range as possible.

That means company-managed projects are there to provide cross-organisation standards, while allowing for some team-level flexibility.  They have been trying to do that (and improving at it) for the 18 years I've been working with it.

Jira has a problem in that it's trying to support organisations that want everyone to work the same non-agile way, at the same time as supporting self-organising agile teams, and, on top of that, scaling up the size of teams and groups at both end of the scale.

(I think team-managed projects are not really relevant to this conversation, I think you and I might agree that they are what they say - just for a single team that's not needing to work with, or report to, other teams?)

[Jimi Wikman]

I don't understand why you argue against it then if you already knew about it? It is a problem if the information in projects can have different structures and possibly even lack certain information, especially when you have issue from different projects in one board.

Being forced to open up your project, so ANYONE can manage sprints, is not an alignment issue between teams. It completely removes the possibility to work with issues in multiple boards, unless you abandon Scrum boards or make project admins Site admins....

Project Roadmaps can not use data from multiple boards. Perhaps you are thinking of Advanced Roadmaps?

Team Managed projects are just snow globes that are black holes within an organization.  Kind of like groups. So I agree, they have no bearing on this discussion.

I do agree with you on the internal issues regarding the different types of projects, but with all focus being on team based projects, I think I know what side will win.

Besides, having a generic setup does not mean you are micromanaging. You can still build flexible setups even if they are shared by everyone.

[Worn 'n Torn]

Glad I read this, thank you both for hashing these issues out.

I've been trying to find some good approaches/practices to set up new project/s for my team.  As we can choose to go centrally managed or team-managed, I was hoping the opportunities abounded.  But after a week I'm still stuck.  It seems team-managed will reach a collaborative ceiling as new projects are setup, and linking to others becomes more important.

The official advice seems more to be go for it, here is a free for all where you go create projects and start.  But it seems this will force all the work for our team to happen in Epics in a single project.  And from the start we will have to structure custom fields to filter issues from each other, and then activate those filters in every view.  Apart from the Click, click, clickity, click, this worries me as the config will become complex over time and the team remain constrained working within the one project.

In an Org where it's been a centrally managed for a while and seems yet to guide the admins, I find myself deciding to setup a snow globe so we can just get our 'worst' done.  Sub optimal in the least.

Hopefully in my ignorance I have the wrong end of a wavy stick though.

[Nic Brough -Adaptavist-]

It's quite a simple choice at the moment - team-managed projects simply aren't built for collaboration, they're only suitable for the cases where you have one team working on something and no other team will ever do anything other than have a quick look at the odd issue in it occaisonally.