Is jira suitable for agile projects?

Question

Hi,

I would like to apologize first for the provocative title. I just want to bring this up to discussion - and maybe I get some answers, which I'm currently looking for.

But let's start with a little introduction. At our company we are developing massively different projects for our customers, which lead us to agile approach. To be more specific, we use Scrum and Kanban – and we are very happy with it… but we are missing some tools to support us. I will focus now on Scrum.

Scrum is not a processes, it’s a framework to develop a process. To be more detailed, every project must have it’s own dedicated process, which is optimized to perfectly suit the needs of the projects and satisfies the customers and developers.

So we are evaluating jira for our agile projects. Greenhopper for planning and Structure for backlog grooming are good plugins so far. Issues and task are also suitable. But the administration concept has some weaknesses.

Like I said, every project must have it’s OWN process. An  tool, specially like jira must support the process with workflows, fields, screens, … which must be maintained by the project members – and not by a global administrator. And it must be prevented that a project administrator can view or change other projects settings. But this is currently not possible, because a project admin can't change the workflow, screen and fields. And an jira admin has access to all projects, which is not preventable.

Are there any idea’s how to solve this. Maybe someone can point me to a documentation.

Thank you for any help!

Jurica Jurjevic · Answer

Thanks Nic and Jobin. Your are both mentioning the problem with project specific workflows. Thats not our experience yet - our company has more then 500 employees and we are developing at least 50 customer projects in parallel. For the last 13 year's we had a central approach - and we are not happy with it. There are to many restriction if we want to change something, because of the side effects for other projects.

The centralized approach may be good for product development - but customer project development is different. And agile / lean means also to improve itself (Kaizen) in high frequence, which could result into e.g. workflow changes.

Don't get me wrong - I think jira should support both (central und project specific) customization as options. Attlasian should improve the support for agile project development. Let the us choose and don't paternalism.

The issue https://jira.atlassian.com/browse/JRA-3156 address the problem is very old. Is there a official statement about it, whether there will be support for it soon - or do we realy need to wait for more than 2 years?

Jobin Kuruvilla [Adaptavist] · Answer

Jazer,

What you said about project admins and system admins are true. Expect that you can prevent system admins from accessing issues etc. Any other change would need a change in JIRA and that will go as a new feature request.

Having said that, IMHO all the things that is done by system admins like workflow changes, field onfigs etc normally aren't frequent. I agree there will be lot of changes in first few months when the system is setup. But once it is setup, the changes will be rare and it is ideal that the changes are manitained by sys admin. I have seen projects which has 10-20 admins and it will be a mess if they have permissions to change workflows etc!

Nic Brough -Adaptavist- · Answer

You need https://jira.atlassian.com/browse/JRA-3156

I would add though - it's actually quite hard to implement because Jira has a lot of shared stuff.  Amending a field can affect every project (e.g. rename "start date").  Similary for workflows, screens, and everything else.

A word of caution on the human side too.  In places where I've worked with tools that do allow project managers to have a lot of control over their project configuration, you rapidly end up in a complete and utter mess.  If you've got 500 projects all doing things slightly differently, you can't get coherent reporting, control, or vision.  It might sound lovely to let teams do things the way they want to, and it works well in small organisations or when you've got independent products and teams.  But it simply doesn't work in medium/large organisations, no matter how flexible your tools are.