How do you keep agile workflows consistent enough for cross-team collaboration in Jira?

[#1]

Agile teams naturally value the autonomy to define workflows in Jira that make sense for their unique processes - whether they're Scrum, Kanban, Lean, or something else entirely. However, as agile practices scale, workflow differences between teams can complicate collaboration. For example, a Scrum team's structured sprints can clash with a Kanban team's continuous workflow, causing hand-off delays or alignment issues in Jira.

We're curious:

• How do you manage Jira workflows to ensure they're consistent enough to enable smooth collaboration between teams, without undermining each team's autonomy to work their own way?

• Have you found specific  strategies, Jira plugins, workflow configurations, or even team rituals that keep your teams cohesive without limiting their creativity?

We'd genuinely appreciate hearing your thoughts and experiences!

[Tarang]

The simplest rule that worked well for me had been a simple choice - one of all teams working on the same cadence.

So for scrum teams being on the same day of start/stop  and sprint cycle. While Kanban doesn't say anything about start/stop, but no reason why a Kanban team had such days where they regroup for shared reflection and refresh for a new start - possibly having new policy from new WIP limits, or agreements in where the bottlenecks are occuring due to systemic issues vs. just being reactive during execution.

[Alex Young]

The most vital thing if folks are going to work differently is cadence. Second to that is making sure that estimations are done consistently and we are improving our ability to estimate.

That being said, I think it is fair to say that as things scale and teams who are used to being more autonomous become more interdependent will need to relinquish some of that autonomy and start thinking about themselves as part of a larger team and that larger team will need to adjust to fit their value stream.

[Walter Buggenhout]

Great question, @Sadhana_Easy Agile!

Cross team collaboration is very much about managing dependencies, right 😛 ... In the spirit of the Agile Manifesto (Individuals and Interactions over Processes and Tools) I am fond of a tip I picked up last year about running effective teams. Apart from working on a continuous basis on improving the internal way of working of your team, make sure to also map out a (short) list of the teams you collaborate closely with. That means:

• teams you are delivering for;
• teams that you are depending on to get work enabled for your team

And literally work out how you (i.e. your team) can exchange information, make shared priority decisions, help each other out and unblock things when necessary.

Making these dependencies visible inside the tools is very useful in helping deliver the input for these conversations inside and across teams. I think the dependency view in Plans (when grouped by Team) can be a helpful instrument, assuming work is properly allocated to teams and the plan does have the work of immediately relevant teams in scope. 

As @Tarang and @Alex Young point out: an aligned cadence does really help to reduce overhead that quite naturally comes from planning and other meetings happening at different points in time. 

[Tarang]

@Alex Young When it comes to estimation, just be careful with the drive for consistency. Yes all teams are to use the same scale for estimation, often its use of Fibonacci number scale or T-shirt size (though as a friend pointed out the difference between T-shirts sizes aren't that far apart). 

Often "consistency" leads teams to estimate time and that's not what one wants to do nor its equivalent "effort". Instead its simply that all teams need to recognize that they are making relative estimates of how complex a problem is amongst a range of other problems that they are to solve. Complexity here is couched in terms of the problem domain & technical or technology in use.

This is important as

1. this is knowledge work (creative work) vs. digging ditches (back break effort). 
2. team members have a range of experiences and no two teams will be the same nor should there estimates be the same even if facing the same problem.
3. this is knowledge work, so differences in estimates for a problem within a team is valuable to surface as this is information often reasoned based on different assumptions
4. estimates are empirical not governed by some scientific principle/law and unlike time aren't precise but are accurate.
5. time estimates aren't reliable as we bias these based on whatever is going on for us moments before estimating. Also we are good at predicting time for things we do in a day or two but not for what we might do next week. I know what time I will take lunch today but I can't say what or how long that might be next week Monday!!

Summary

- Consistency of Scale and dimension in the space of estimation i.e Domain Complexity & Tech Complexity (flip side of the coin of complexity being uncertainty)

- Derive time as in what is the forecast based on the teams average run rate (average velocity) for body of work and not just 1 item.