Agile product development teams optimally comprise four to six members, which maintains the work’s efficiency. When the developed solution is larger, it is better to increase the number of teams rather than enlarge one team. You start running into problems when the systems you develop are so large that the number of teams increases too much. With two or three teams, you do not yet need much coordination, but when you start having more teams, the complex dependencies of matters start accumulating to the extent that it is better to adopt a scalable enterprise resource planning system.

SAFe – the Most Popular Approach to Making a Large Organization Agile

SAFe, i.e., the Scaled Agile Framework, is the most popular system for this purpose, used by thousands of companies around the world, ranging from medium-sized production teams of a hundred people to enormous multinational product development giants. At Contribyte, we have been familiar with SAFe from the start.

At the moment, SAFe is already on version 4.5. This version introduced new terms and methods for making operations even more agile, such as the Continuous Delivery Pipeline, Lean User Experience and Scalable DevOps.

SAFe can easily be utilized by a program encompassing a few teams, but it is also designed from the start for larger projects. When moving from the Program level (Essential SAFe) to larger projects, the SAFe versions Large Solution and Portfolio are applied. The whole entity may at first seem challenging to internalize, but it is actually not difficult in any way, especially if you boost your learning process with SAFe training for key persons.

Atlassian JIRA – a Flexible and Versatile Enterprise Resource Planning System

When talking about popular systems that assist with product development, we cannot hide the elephant in the room, i.e., the enterprise resource planning system (used to create stories and bug tickets and monitor and guide their implementation). The most popular system of this type today is Atlassian JIRA. It is not a perfect system, but it is the best for many purposes.

It is no coincidence that JIRA is currently the most popular ticket system for product development. It is relatively easy to learn and is excellently suited for guiding the work of one or more teams. Its range of accessories is unbeatable, and if it has one weakness, it is its management side, which takes some time to get used to and learn. A capable partner can also assist with this, taking care of the most difficult things on behalf of the organization.

SAFe and JIRA, a Match Made in Heaven?

This situation with two popular systems will eventually face the question of whether using them together is a) like a forced marriage or b) the love story of the century or c) something in between! Well, at Contribyte we think that SAFe and JIRA actually fit very well together. In this blog series, we want to shed some light on how this wedding should be arranged.

The User Story at the Heart of Everything

Just like in every type of coexistence, you should first understand each other to facilitate the communication. So let’s start by comparing the concepts of each system.

Of course, both JIRA and SAFe offer concepts for how a larger system under development can be broken down into smaller pieces until you reach a level at which one team can fit the item under development into one development sprint. At this lowest level, both systems use the same terminology: User Story.

However, at the next level SAFe defines that a development project covering more than one sprint is called a Feature, rather than an Epic. Even though it may seem that the Epic level is at a very “high level” in SAFe, you should not let it scare you. In SAFe, Epic refers to a separately funded project that covers more than one Program Increment, i.e. typically more than five sprints. Of course, in terms of time this takes at least a few months.

Table 1: story hierarchy

Sprints and iterations

Let’s take another concept, i.e., sprint

Table 2: iteration hierarchy

Contribyte’s recommendation

Are you confused yet? There is nothing to worry about because there is an easy solution to the situation! Because JIRA largely lacks an iteration hierarchy (as can be seen from Table 2), we can adopt the term Program Increment directly from SAFe in this regard. At Contribyte, we recommend adopting this term, as it is at the core of SAFe, and the strongest added value offered by SAFe may be its Program Increment planning session. If you otherwise need help arranging a PI planning session, we have helped dozens of companies launch their PI sessions!

In other respects, we recommend the use of JIRA terms. To summarize, teams have sprints, and the agreed number of sprints (usually four to six) forms one Program Increment. Work that fits into sprints is called a Story, while work that does not fit into a sprint is an Epic. The company management leads the work with Themes. A piece of cake!

Wedding of the Century. Do You Have the Rice at the Ready?

As you can see, there is no use in taking offense at the differences in terminology and giving people the silent treatment. SAFe is an excellent scaling framework, but just like any other general guideline, it ALWAYS requires company-specific application. Of course, the choice of terms I have presented here is not the only option. The most important thing is to make conscious choices regarding what the different terms mean and then make sure that everyone in your company understands and uses the terms in the same way.

The next parts of this blog series will discuss the perhaps most essential part of SAFe, i.e. the Program Increment planning session, and how the planning, holding and aftermath of the session should be linked to JIRA.

Contribyte is the leading expert in Atlassian in Finland, and we also have a great deal of experience in assisting companies advance on their SAFe path. This makes us the perfect best man for a SAFe + JIRA wedding in your organization!

We can also provide you with other assistance for agile activity, team coaching, and training in Scrum, Kanban, product ownership, product management, and service design.