5 Jira Align Capabilities That Provide Local Autonomy

[#1]

Balancing local autonomy with the need for standardization

I often get questions around what needs to be standardized within the platform, versus what can be configured to accommodate the different practices of teams in other areas of an organization. From “do all teams need to be on the same PI cadence” to “do Kanban teams need to estimate user stories”, teams are always looking for local autonomy. But leadership needs some standardizations within the system, so they can have informed conversations higher up on in the organization. While looking to strike a balance, there needs to be some level of consistency in data, in order to drive conversations and reporting around commitments made and kept.

Outside of any platform, tool or framework, few seem to debate what day it is, the month, and the year. We agree there are 7 days in a week, 12 months and 365 days in a year. But that’s because we’ve generally agreed to use the Gregorian calendar. If you subscribe to the Julian calendar, any given event during the years from 1901 to 2099 inclusive, the date according to the Julian calendar is 13 days behind its corresponding Gregorian date. This is exactly why we have standardized which calendar to use. We need to have a shared understanding of time. We want to eliminate unnecessary friction and waste by eliminating the misunderstanding.

The goal of a system of delivery is to maximize outcomes relative to controls like quality, time and cost. The goal of a system of improvement is to improve quality and eliminate unnecessary waste, reducing time to market and reducing total costs.

While trying to improve and optimize the whole of the organization, we need to be conscious of over-standardization. If we are too ridged and too focused on standardization, we can actually impede flow and be suboptimal in our ability to deliver value. Because we’re trying to unleash the potential of every team, we need to strike a balance between having a shared understanding around people, work, and time while also allowing teams to determine how to best operate locally.

Here are 5 examples of Jira Align configuration options that provide local autonomy.

---

Local autonomy on a portfolio level

(1) PI cadence

Not all portfolios need to be on a single PI cadence. Though we do recommend for an entire portfolio (collection of programs or ARTs) to be on a single PI cadence, the portfolio can choose to be an a unique cadence from others within the organization. The major complaint from people is if Program Increments and Sprints all start/end on the same day throughout the whole organization, how would you ever find a room for team events? I would challenge you to think of the Program Increments like any timebox on the calendar. It allows us to have a shared understanding of time boundaries. Plan your events for times that make the most sense for you and your teams. Nobody is saying you have to conduct a 2-day PI Planning event on the first day of the PI. If you have sufficient ready backlog and your dependencies are identified and committed, the PI Planning event can be much shorter and be more focused on reinforcing a shared understanding of vision and mission and less focused on team breakouts and writing stories. The event can be hosted a few days before before or after the PI boundary and it’s not going to impact your metrics.

Just know that if you have two portfolios on different PI schedules, covering overlapping timeframes and work, you’ll need to include both PI schedules in the Epic work object. Imagine if one portfolio had a PI for a season and one portfolio had a PI for each month. [Autumn 2020] = [Sep 2020] + [Oct 2020] + [Nov 2020]

(2) Value Streams (Process Flows)

Not all program and portfolio level value steams (process flows) need to be the same. Document the process steps for how Themes, Epics, Capability, and Features should flow through your system of delivery for your different programs and portfolios. Look for common design and flow patterns. Align programs (in portfolios) to the value steams that best suit them.

(3) Enable Capabilities for select portfolios

Capabilities can be turned on for specific portfolios within an instance. If Multi-Programs is turned on, then you should not have a mixture of portfolios that have capabilities on and off. (this could result in unusual reporting rollups).

Enabling capabilities puts a layer between epics and features. An epic will be associated with capabilities and capabilities will be associated with features. The direct epic and feature association will no longer be possible. Once capabilities are enabled, they cannot be turned off.

(4) Scrum vs Kanban teams in a PI

Scrum and Kanban teams can co-exist within a PI. If your team type is set to Scrum, you're focusing on meeting commitments within Sprints. If your team type is set to Kanban, you’ll be focusing on maximizing flow relative to dates. The anchor sprints will provide a crosswalk, so when shared PI commitments and dependencies are being discussed, you have a shared understanding of time.

(5) Some Kanban teams not estimating stories

Some Kanban teams do not need to estimate their stories. For this to be true, there is an assumption that their work is standardized and therefore they are looking at units of work instead of size. That said, the program and portfolio are still trying to understand delivery and budget capacity. If your team indeed has standardized work and the action of estimating stories no longer provides team level value, ensure your team type is set to Kanban Team and enable Auto-populate Estimate. List the number of points that you believe best represent the size and complexity of your standardized work. If your work is not yet standardized and your Kanban team has not yet reached an optimum flow rate, it’s recommended that you continue estimating stories.

---

Standardization

Terminology

Terminology is a platform setting and impacts the entire instance. In order to have a shared understanding of work, you need common terminology. One portfolio may call a portfolio level work object an [Epic] and another portfolio may call it an [Initiative]. This causes confusion and waste, if these two portfolios have shared commitments. 

To aid in change management, when you initially integrate Jira with Jira Align, you may choose to rename the Jira Align [Epic] object to [Initiative]. After teams have been provided the proper training and had time to acclimate to Jira Align, you can change the name back on a future date. As you onboard more portfolios, programs and teams, consider revisiting the terminology, as thinking or practices may have evolved.

Integration with Jira

Jira Software is built for every member of your organization to plan, track, and release great software. We know that every team has a unique process for shipping software. You can use an out-of-the-box workflow, or create one to match the way your team works. These things have to be considered, if you choose to integrate that work with Jira Align. Understanding standardization versus local autonomy options on a Jira integration level will have to be a separate post all to itself. Until then, here are a few links to get you started.

• Jira Align and Jira Integration Best Practices and FAQ

• Jet: Agile at Scale Analysis for Jira