MEASUREMENT IN AN AGILE TRANSFORMATION AT SCALE (PART 1) – THE KEYS TO AN OPTIMAL JIRA CONFIGURATION

In today’s dynamic business landscape, the ability to adapt quickly and effectively to changes is crucial.

Agile transformation, with its iterative and value-centric approach, has become a key enabler for many organizations seeking to remain competitive and innovative. However, achieving large-scale agile transformation requires more than just adopting an agile mindset; it is also essential to have the right tools, optimally configured.

At the heart of many organizations is Jira, a widely adopted project management and request tracking tool. Its flexibility and ability to adapt to various agile methodologies make it an important ally for teams seeking to manage and monitor their progress. But without proper configuration, Jira can quickly become a complex maze, hindering more than facilitating agile value flow.

In this first part, we’ll explore how careful configuration of Jira can not only facilitate the implementation of value streams at scale, but also increase efficiency, transparency and collaboration within teams.

Whether you are a Scrum Master, Product Owner, agile team member, or organizational leader, these insights will help you turn Jira into a powerful engine for your agile journey.

Jira, a pivotal platform for Agile@Scale

Jira, developed by Atlassian, is a project management and request tracking platform widely recognized in the world of agile practices and beyond. Its versatility makes it an essential tool for many organizations, from dynamic startups to multinationals.

Jira works on a project-based model, where each project can be configured with its own workflows, task types, and security settings. Within these projects, tickets (often called “issues”) are the basic units of work. They can be classified into different categories (such as bugs, user stories, or tasks) and progress through the defined workflow, reflecting their lifecycle from start to finish.

Users interact with these tasks through customizable dashboards, which provide an overview of current projects and their current status. Dashboards can be configured to display relevant information, such as tasks assigned to a user, the status of current sprints, or urgent priorities.

In summary, Jira is a powerful and adaptable tool that, when configured well, can become the central pillar of agile project management, facilitating communication, planning, and tracking progress in dynamic and fast-paced environments. evolution.

The different organizational models at scale under Jira

Jira gives great freedom in the organizational structure of the teams involved in a large-scale agility program.

The hierarchical model

This mode makes it possible to clearly distinguish the different hierarchical levels of organization of a large-scale Agile program.

Each hierarchical level is represented by a Jira project, containing the ticket types associated with each level.

In this example we have 3 hierarchical levels:

  • Portfolio: Represents the highest level of monitoring of all value flow activities
  • ART Flow: Represents a Train (Program), intervening on a development value chain
  • Team Flow: Brings together all the teams involved in the activities of an ART Flow

It is a model very representative of the organization proposed by the SAFe Framework of Scaled Agile, on its SAFe Portfolio model.

The Tribes model

This mode of organization is based on the Feature Team organization model popularized by Spotify, but also on the SAFe Essential model of the Scaled Agiled SAFe Framework.

This model is centered around small cross-functional teams called “Feature Teams”.

or “Team Flow” (SAFe).

Each team is autonomous and has all the skills necessary to design, develop, test and deploy its features.

Feature Teams/Teams Flow focus on a specific aspect of the product rather than a specific project or task. This allows them to focus on creating value for the end user.

In Jira this can be translated into the following organizational mode:

  • Create a Jira Project by Tribe/ART Flow which will bring together all the Features to be processed by the Tribe/ART Flow Squad/Team
  • Create a Jira project by Squad/Team, which will contain the details of the activities to be carried out on the Feature: Story, Anomaly, Task, etc.

The Team model

This mode of organization is suitable for teams with high autonomy over their activities and low dependence on other teams in the organization.

The Overall model

This mode of organization aims to bring together all of the organization’s activities within a single Jira project.

This method of organization may seem ideal because all activities and all teams are grouped within a single project, but it can quickly prove complex in its daily management, particularly in monitoring activities at team level. , program and portfolio.

In addition, this type of organization will generate the creation of a significant number of dashboards within the same Jira project.

Configure Jira for a SAFe (Scaled Agile) organization

In the rest of this article we will base ourselves on the most popular SAFe (Scaled Agile) agility framework at scale, in order to present how to configure Jira for an Agile@Scale organization.

We will base ourselves on the SAFe Portfolio model, comprising 3 levels of monitoring:

  • Portfolio Flow
  • ART Flow
  • Team Flow

Create Portfolio Flow items

Jira does not have a ticket type at the SAFe portfolio level. The EPIC Jira type is a false friend which represents more of a Feature associated with Story, Bug, Task.

To create Portfolio level items, you can create a Custom Issue-Type:

  • EPIC
  • ENABLER EPIC

If you do not want to multiply the types of custom ticket, you can just create the EPIC type, as well as a custom “Request type” field which can take 2 values:

  • Functional
  • Technical (Enabler)

This customized field will then be associated with the new EPIC ticket type.

You then just need to integrate the fields necessary for its description and use into this new EPIC type.

Create ART Flow level elements

A Portfolio can be associated with several ART Flows (Train SAFe).

An ART Flow is made up of “Feature”, “Enabler Feature”, “Tech Debt & Maintenance” type tickets.

As noted previously, Jira has the “EPIC” ticket type which actually represents the “Feature” level of SAFe.

In order to use this type of ticket clearly, you simply need to rename the “EPIC” type to “Feature”.

For the “Enabler Feature” type, you can either create a new ticket type or use a “Request type” field which will take 2 values:

  • Functional
  • Technical (Enabler)

For the “Tech Debt & Maintenance” type, I advise you to create a new type of ticket, in order to clearly distinguish maintenance and technical debt reduction activities.

Create the EPIC – Feature link

We have created a new “EPIC” ticket type (and where applicable an “EPIC ENABLER” type) at the Portfolio Flow level.

At this stage there is no automatic way to associate an EPIC with a Feature in Jira. Only the “EPIC JIRA” (Feature) ticket type has a natural and automatic link with Story, Bug, Task Jira type tickets.

To resolve this problem, we will use a Custom Link, which will define the relationship between an EPIC and a FEATURE.

Jira already offers a certain number of custom links as standard. Simply choose the most appropriate link or create a specific one.

In our example, we could use the “Parent” link.

This case is also applicable to new ticket types that you would have created at the ART Flow level to manage the association with Flow Team level tickets.

Create the Team Flow Level

This level is the easiest to organize. Jira offers different types of team-level tickets as standard: Story, Bug, Task, Sub-Task.

For the “Enabler Story” type, you can either create a new ticket type or use a “Request type” field which will take 2 values:

  • Functional
  • Technical (Enabler)

If you have created a “Tech Debt & Maintenance” type ticket for the ART Flow part, then you can also use it at the Team Flow level. Otherwise, you could use the “Task” ticket type and even rename it if necessary.

Organize the Increments of an ART Flow

An ART Flow is made up of several Increments, which are generally 3 to 4 per year, depending on their duration.

All teams at the Team Flow level will work on each Increment.

In order to properly identify each Increment, you can use the standard Jira “Fix version” field, which you can manage on the Release management page of a project.

However, the Fix Version field is often used for versioning purposes of deliveries and cannot always be used for Increment management. In this case, you can create a custom “ART Increment” or “Program Increment” field. This field can be free entry or associated with a list which will contain the ART Flow Increments and will also avoid entry errors.

Example: ART FLOW Wiveez – Custom field “ART Increment” list

  • ART PI 23-T1
  • ART PI 23-T2
  • ART PI 23-T3
  • ART PI 23-T4
  • ART PI 24-T1
  • ART PI 24 T2 …

This field can be associated with ART Flow level and Team Flow level tickets.

Organizing Iterations of an Increment

An Increment lasts between 8 and 12 weeks and is made up of 4 to 5 Iterations (Sprint) of 2 weeks each (generally).

If you have implemented the Hierarchical model, then each team at the Team Flow level is identified in Jira via a separate project.

When creating a new Iteration, Jira will create an incremental title with the project code as a prefix.

Example :

  • Team Alpha
    • Sprint 1 = WTTA Iteration 1
    • Sprint 2 = WTTA Iteration 2
    • Sprint 3 = WTTA Iteration 3
  • Team Beta
    • Sprint 1 = WTTB Iteration 1
    • Sprint 2 = WTTB Iteration 2
    • Sprint 3 = WTTB Iteration 3
  • Team Charlie
    • Sprint 1 = WTTC Iteration 1 …

You also have the option to customize the name of each sprint as you see fit.

The problem remains that with different names between the teams for the same Iteration, it becomes impossible to consolidate the data of the entire Team Flow, for an Increment and an Iteration.

To address this issue, simply create a customized field, which could be called “ART Iteration” or “Iteration Program” which will allow each team to group the activities of an Iteration under the same title.

This field can be free entry or associated with a list, in order to avoid entry errors.

Example :

  • ART PI 23-T1-Iteration 1
  • ART PI 23-T1-Iteration 2
  • ART PI 23-T1-Iteration 3
  • ART PI 23-T1-Iteration 4
  • ART PI 23-T1-Iteration 5
  • ART PI 23-T2-Iteration 1
  • ART PI 23-T2-Iteration 2
  • ART PI 23-T2-Iteration 3
  • ART PI 23-T2-Iteration 4

Create your PI Objectives

The notion of objective in the SAFe framework (Scaled Agile Framework) refers to specific and measurable goals that an Agile team aims to achieve within a defined time frame.

These goals are aligned with the broader goals of the organization and are designed to deliver value to customers in an iterative and incremental manner. They are often evaluated and adjusted during retrospectives to ensure alignment and continuous improvement.

Jira does not offer an “Objective” ticket type as standard. You must therefore create a new type of ticket, which you can name “Objective” and which can be used at the ART Flow level and at the Team Flow level.

You can associate the following fields with this type of ticket, which will allow you to monitor the management of the Objective:

  • A title
  • A description
  • Expected value (PBV – Plan Business Value)
  • The value achieved (ABV – Actual business Value)
  • Indication of committed or uncommitted objective (Committed; Uncommited)
  • The associated increment
  • The associated team

You will then be able to monitor the progress of the Objectives of an Increment or a Team via a dashboard at the ART Flow and Team Flow level.

Identify your Teams Flow

It is very easy to find tickets associated with a team in Jira when a team is attached to a separate project.

This becomes more complicated when you have set up Global mode where all teams are part of the same project.

To allow you to distinguish the activities of each team, you can use the standard “Team” field if it exists in your version of Jira, otherwise it is preferable to create a custom “Team” or “Equipe” field where you can enter the name of the team associated with a Team Flow level ticket (Story, Enable Story, Objectives, etc.).

Conclusion

Mistakes that some organizations often make include:

  • not training their teams in the use of Jira;
  • not affording the services of a certified Jira administrator;
  • not adapting Jira to its context

Jira offers numerous configuration possibilities to adapt to your Agile@Scale organization and provide you with the tools necessary for optimal management of your development value stream.

In the case of our SAFe Portfolio organization, this is what your Jira setup might look like.

In the second part, you will discover how to configure the Wiveez application to generate flow measurement indicators and objectives, for an Agile@Scale organization, at the ART Flow level.