nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Facilitating Self Organising Teams in Large Jira Instances in Agile organisations

Wouter Bruinings

Discussion Topic: Facilitating Self Organising Teams in Large Jira Instances in Agile organisations

Hi everyone, I’m interested in starting a discussion on how Jira admins in large organizations can support the Agile Manifesto principle of self organization, while maintaining a manageable and cost-effective Jira environment.

In many cases, self-organization in Jira is interpreted as allowing teams to develop custom workflows tailored to their specific processes. However, this approach can become unsustainable and expensive to maintain as the number of custom workflows increases.

I’m curious to hear from fellow Jira admins and Agile practitioners about your strategies and best practices for facilitating team self-organization in a way that doesn’t lead to an overwhelming number of custom workflows.

Here are some specific points to consider:

1. Standardization vs. Flexibility: How do you balance the need for standardization with the desire to allow teams the flexibility to adapt workflows to their specific needs?

2. Best Practices for Custom Workflows: Are there any guidelines or best practices you follow when creating custom workflows to ensure they are maintainable?

3. Leveraging Jira Features: How do you use Jira’s built-in features (such as components, labels, and custom fields) to provide teams with the flexibility they need without resorting to creating custom workflows?

4. Governance and Oversight: What governance or oversight mechanisms do you have in place to manage the proliferation of custom workflows and ensure consistency across the organization?

5. Training and Support: How do you educate and support teams in using Jira effectively so they feel empowered to self-organize without relying heavily on custom workflows?

Looking forward to hearing your thoughts and experiences!

Best regards,

Wouter

Comments

Elliot Jones_wpplqa

I think what's interesting in this post, is that main talking point is the Agile Manifesto that prefers communication and culture over process....the consideration points seem to lean on process over anything.

Custom workflows are part of process, not really behaviour and collaboration.

I have found that if the culture and collaborative nature of a studio/organization is on point, the workflow/process stuff can follow suite and be adjusted...HOWEVER I would always recommend a base that is agnostic to the organization.

For example, I have 2 scrum teams to serve, and I also work with multiple other teams like a Central Tech team for our services, Marketing, CRM, LIveOps etc. One thing they said got in the way was the inability to move issues easily, because the previous leader had set up custom workflows for EVERYONE. This actually hindered us.

There should be a base scaffold that you can build on, but it must (IMO) but consistent because ultimately you want visibility when you can step up and back.

From a process perspective, I have massively leaned into using the "Team" field and ability in Atlassian. It has allowed me to create a single source of truth that shows what we're all doing, which enables discussion on how to achieve common goals together.

TLDR: Processes only work if there is a belief in the collaborative nature of what we do.

Morgan Watts_9u2pqd

Could you expand further on how you leverage the "Team" field. I've been tempted to start using it our processes to see if it cleans up communication.

Currently, I use custom fields, and our teams mark who the responsible user is from their team for that body of work. For example, if it's a contract deliverable it'll say, "analyst responsible" and automation is written around that name.

It's mostly fear of the unknown on my part. I'm the sole site-admin at my company so learning Jira while learning all the constant new functions is a fun game of "whack-a-mole."

Keith Sottung_u0urw2

Great questions. Looking forward to the responses.

Antonio Valle _G2_

Hello @Wouter Bruinings . This is a very interesting (and important) question. From my point of view, there is a point in the concept "large Jira instances" and "agile orgs".

Large Jira instances mean the need of taking care of the instance, dedicating a lot of efforts on maintaining it coherent. Governance is the word, but then the manifesto says "hey, everybody can self-organise"

Governance of agile organisations is a very interesting subject :-)

If you allow every team leader to be a Jira admin so they can organice themselves, you quickly will be swimming in a sea of madness . How many priorities (thanks god we now have priority schemas), statuses, resolutions and customs fields do you have?

Yes, of course you should facilitate self organised teams but also must rationalise how this self-organisation gets translated into a tool that is used corporate-wide

So my advise is to use the project admin roles, delegate them as much as possible and establish a quick method to attend modifications. And try to keep things as much standardized as possible since it will ease the maintenance of your large instance and also will enforce collaboration, conversations and communication between teams.

Self organisation is good until it becomes a mesh of different tribes that talk different languages.

You can write something like <<"DONE" is the word we use to express finished work. So please don't use "FINISH", "COMPLETED", "DONE", "END" and "WE DID IT"... just use DONE, please, and then agree a DoD with your team>>

Antonio Valle _G2_

What I don't like about Team field is that anybody in the organisation can create a new team. In large instances we always end with "test" "my test" "my team" and so on... I would like to have a more controlled teams environment.

Yes, I know, self-organisation.. yes...

A big power comes with a big responsibility. And not every member of every organisation is in this maturity level.

Elliot Jones_wpplqa

Everyone having the ability to make a Team and having the permission are two different things however. If you set the guidance that only certain individuals have the permission to do, then it becomes a behavioural issue if someone decides to go against that request.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-administration

agile

scale

scaled