Jira with many projects and large teams?

[James Barwick]

The general concensus with our management is that Jira is completely unacceptable for large teams and companies with many projects.

Such as, our team of more than 300 engineers and developers. There are comments here on the board that say "what to do if you have more than 200,000 issues"....We could see that in less than a year.

What do you all think? Is JIRA an acceptable solution for large teams?

[Nic Brough -Adaptavist-]

A brief answer is that there are a suprising number of installations out there that are a LOT bigger than that. I've got two clients in my past that were on 1.5 million issues/10,000 users and 0.5 million issues/22,000 users. It can work very well

It very much depends on your processes though, and does require you to look after it properly (the same probably goes for any large system to be fair). I usually find that the main problem with interdependencies and cross-team working is little or nothing to do with the software and all about process, structure and communications within the organisation.

[James Barwick]

Thanks for you response. Good to know that the installation size isn't an issue.

The next is the crux of the requirement: Communication. With 10,000 users or 22,000 users, how does the "cross-team working [have] little or nothing to do with the softwre and all about process..." ? Should not the software facilitate cross team communicaiton and process?

I think this is where the "software" will fail. "Little or nothing" isn't going to cut it. The software MUST have EVERYTHING to do with corss-team commuication and process.

Workflows MUST work across teams. Interdependencies MUST be catalogued, configured, and setup within the workflow.

If JIRA cannot do this, then we will probably have to skip it.

Does anyone know of any alternatives?]

[Nic Brough (Adaptavist)]

Sorry, that's not what I was getting at. Jira can do shared processes and communications - the problems I've run into is finding that people simply don't communicate properly and when you say "look, if you're all working in Jira", teams will tell you that they all want to do it their particular way and everyone else is wrong.

It's not a matter of the software not matching up, it's that the humans won't work together.

Saying "workflows must work across teams" is all well and good. But it breaks as soon as your humans can't agree on common workflows. Jira supports multiple workflows, and there's no issue with saying "you two teams are doing two different things, so you need different workflows", but if you've got teams doing essentially the same thing and they can't agree, you're stuffed, no matter what the software it.

[James Barwick]

OK. But let's assume that we have all adopted a consistant workflow. Let's assume that we want excellent communications channels and automated workflow between teams. Let's assume that everyone is on the same page.

So, how can JIRA facilitate the process?

I think this will be my last attempt to ask the same questions. It seems that JIRA cannot help facilitate a cross-functional multi-team coordination.

We attempted to take a backlog of issues that we have in Excel and setup a process in JIRA to help us process the backlog.

Due to the cross-functional communications requirements and interdependencies, we could not create a workable workplan in JIRA (without a large amount of cross-checking and manual efforts).

Now, of course, this could all be because we lack knowledge and experience in JIRA. Hence my questions posed here.

Any advice on setup/configuration/modules that could help with this would be greatly appriciated.

[Nic Brough -Adaptavist-]

Ok, so if you all agree on the processes, the question becomes "how do I make the software do what we need?"

The answer there is based entirely on what you need. It's fine to say "cross functional multi team co-ordination", but you need to define what you want from that. The obvious stuff is simple - allow all users to see all the project data they might be interested in. You almost certainly want them to be able to comment and/or link them too.

But beyond that, it's impossible to say how to do it without a clear definition of what you actually want. What does a "workable workplan" mean to you?

[James Barwick]

What I want: When an issue is raised, it can effect 20 different projects and sub-components. From hardware teams to software teams. If a change to either hardware or software is made, then each of the teams that is effected by that change must be notified to add to the workplan tasks to test and/or verify that a change has not adversely effected their project. If a new development is in place, from Scrum to Kanban, the development workflow process from software to hardware or hardware to software teams must be fluid and defined without the need to manually communicate between the teams. This must be 'defined and automated' When performing resource planning, some resources cross teams. Especially in managerial roles. This must be considered when scoping effort and planning roadmap release dates. Again, the software should facilitate this process. I don't want to do anything more or anything different than 1000 other 'large multi-functional multi-team' organizations.

[James Barwick]

How to handle project interdependencies?