How can we best get workflow-alignment for Agile at scale, while retaining local autonomy?

Question

Is there a way to administer workflows that allows very simple, broad-brushstroke high-level statuses for a global level. Local teams then having almost unrestricted autonomy with their own workflows, as long as they can be mapped to the global statuses?

There are 2 stakeholder user stories to balance:
As a global stakeholder, I need a reasonably consistent overview information about requirement progress across teams, so that I can understand progress and spot possible impediments.

As a local agile team, we need to be able to quickly adapt our way of working on the basis of regular inspections (retros), without having to always refer to global administrators in the organisation.

Edit: As suggested in Walter's reply, here's a simplified concrete illustration, for a shared User-Story issue type, single large project in Jira, many local sub-teams:

Global admins might require all teams to align to some broad brushtrokes with their workflow statuses, say To Do -> Requirements Refinement -> Active Development -> Done.

A local team in Canada might evolve towards To Do -> Req Analysis In Progress -> Dev In Progress -> QA In Progress -> Done

A local team in South Africa might go for To Do -> Req Analysis In Progress -> Ready For Dev -> Dev In Progress -> Ready For Code Review -> Deployed to QA -> QA In Progress -> Done

.. and so on.

Marguise · Answer

Thanks Walter. At a glance that doesn't really seem to cater for what amounts to single-project, shared item types, many teams. The question is whether items could align to more than one workflow, at different levels of granularity (not dissimilar to the way we can map multiple statuses to board columns, I guess).

I'm not sure migrating backlog items to different workflows quite fits the use case. Maybe that should have been my first question, whether single-project across many scaling agile teams is best-practice. That aside, here's a simplified concrete illustration, for a shared User-Story issue type:

Global admins might require all teams to align to some broad brushtrokes with their workflow statuses, say To Do -> Requirements Refinement -> Active Development -> Done.

A local team in Canada might evolve towards To Do -> Req Analysis In Progress -> Dev In Progress -> QA In Progress -> Done

A local team in South Africa might go for To Do -> Req Analysis In Progress -> Ready For Dev -> Dev In Progress -> Ready For Code Review -> Deployed to QA -> QA In Progress -> Done

.. and so on. Can local teams, with individual boards within a single project, align their workflows on any kind of common denominator within that one project, without a proliferation of item types? It sounds like Jira is not designed to work that way. So what is best practice in that case?

(Apologies if this eventually appears more than once. There seems to be a bug with the Edit Reply feature.)

Marguise · Answer

At a glance that doesn't really seem to cater for what amounts to single-project, shared item types, many teams. The question is whether items could align to more than one workflow, at different levels of granularity (not dissimilar to the way we can map multiple statuses to board columns, I guess).

I'm not sure migrating backlog items to different workflows quite fits the use case. Maybe that should have been my first question, whether single-project across many scaling agile teams is best-practice. That aside, here's a simplified concrete illustration:

Global admins might require all teams to align to some broad brushtrokes with their workflow statuses, say To Do -> Requirements Refinement -> Active Development -> Done.

A local team in Canada might evolve towards To Do -> Req Analysis In Progress -> Dev In Progress -> QA In Progress -> Done

A local team in South Africa might go for To Do -> Req Analysis In Progress -> Ready For Dev -> Dev In Progress -> Ready For Code Review -> Deployed to QA -> QA In Progress -> Done

.. and so on. Can local teams, with individual boards within a single project, align their workflows on any kind of common denominator within that one project, without a proliferation of item types? It sounds like Jira is not designed to work that way. So what is best practice in that case?

Walter Buggenhout · Answer

Hi @Marguise,

Have a look at Automation. It has rules available to help you trigger workflow transition from one workflow to another.

Do spent enough time to sketch up how you imagine your high level statuses and the issue (type) you would associate them with, and be aware that you will need to be very clear about what the integration points (statuses) will need to be for the teams designing their own process.

Coordination from the top level process will be key to achieve the integration and balance between centralised coordination and team level autonomy.