The Agile method is normally designed for teams of about a dozen people. The Scaled Agile Framework (SAFe®) allows larger organizations to implement an Agile system by cutting down the enterprise’s work into smaller parts until it reaches a level that is suitable for the Agile method.
This method cuts the work on several levels:
- At the unit level, a team can vote on the Features they wish to develop. These Features are created by the Product Owner and refined by the Scrum Master. The team then divides the Features into their respective Stories, which are likewise divided into two-week Sprints. Every five Sprints a Program Increment (PI) Planning is conducted with all the development teams, who then again decide the next steps for development.
- All these teams unite to form the Agile Release Train (ART), driven at the Program level. The Business Owner decides on which features will be in the next release, which in turn are integrated into the ART. Teams from the same ART work on the same Program and therefore must synchronize their releases and manage which components are dependent on the others. The ultimate goal is to release functionalities quickly and regularly.
- The Large Solution Trains are the next level up. They are used to build large and complex solutions that require the coordination of multiple Agile Release Trains. They group the ARTs around common themes, known as Capabilities. These deployments should normally be geared around providing a solution to the corresponding theme.
- Finally, the last level is know as Portfolio. Its objective is to align the programs with the enterprise’s strategy and vision, combining the Solution Trains into Value Streams (which on a higher level, define Portfolio-level business objectives and organize Agile Release Trains) and applying them to a problem at the enterprise level via Epics. This level also takes into account the risks associated with the investment.
We’ll not linger too much on methodology, as the theory is rather extensive, but rather on how it relates to Atlassian tools. Yet SAFe is a fascinating topic, so if you’d like a deeper dive into the subject it’s available on the official Scaled Agile Framework website.
SAFe and Jira Software
In the SAFe methodology, each team is free to choose their own approach as to how they work. Jira Software offers tools to implement Kanban and Scrum – the two dominant Agile methodologies.
Note: These methods are clearly named in the schemes defined by SAFe. You can find the SAFe glossary here.
The objective is to centralize all the information, allowing all teams to have the widest visibility of the Program
An example of a possible implementation
One project, three types of issues
Here we take into account that there is one Program which represents the project (the key used here is PROGRAM for the following examples. This project consists of the entirety of the issues).
The Business Owners’ mission is to add the Features to the project, along with validate and verify their completion.
During the PI planing, the different development teams have the possibility to assign themselves these Features and create the relevant Stories. The Sub-tasks can likewise be created in each Story to facilitate the division of work to be carried out in each different Sprint.
Being assigned to a group
The development teams should be capable of assigning themselves issues in order to later create Stories and Sub-tasks, thus isolating their work from the rest.
If you wish to remain as close as possible to the native Jira Software functionalities, you can use a personalized field of type Group Picker which you can call Assigned team. From this field, we can create an agile board for each team.
Visibility for the team
The board will be defined using a JQL filter. For more details, check out our Ultimate Guide on JQL here. At this point we’ll need to move beyond Jira’s native features and use apps, as we’ll want to incorporate the three levels of issues (Features, Stories, Subtasks). Valiantys’ app Exocet allows us to add operations to create Stories and Subtasks and copy the value in the field Assigned team, level by level. This option is a a bit complex to configure, however simplifies considerably the query needed to search your boards.
The integration of a new team can be executed by following these simple steps:
- Create a group and define its members
- Give this group the same rights as the others (system authorization and project roles)
- Create the board
Visibility at a higher level
Les Business Owner can likewise have a particular role defined in Jira, as they can create a board to follow the overall progress of the different teams. Below is the JQL query used for this board:
Use linked issues to keep the lines of communication open
Linked issues can be an important tool for breaking silos between teams. If a feature needs to be developed by one team before another team can take over a start the next phase of development, the linked issue will show immediately what the blocker is, who is in charge of the problem and how it will get resolved. This will allow the teams to focus on other tasks, thus using their time efficiently.
Issue type: Enabler
According to the SAFe glossary, “Enablers promote the activities needed to extend to Architectural Runway to support future business functionality. These include exploration, infrastructure, compliance, and architecture development.”
So why aren’t enablers treated like other issues in Jira? These elements by nature are resolved by external factors and not the internal teams. By linking them as a different type of issues, at least the teams will be able to access information of the enabler to see its progress, estimated resolution date, information on its management, etc.
Limitations of Jira Software
As we’ve seen here, SAFe at its basic level, known as the The Essential SAFe configuration, can be executed by Jira Software with a little help from Marketplace apps. However, there are still some aspects that are missing from the puzzle.
The main limitation comes from the different nomenclature between Jira and SAFe. For example, Features in SAFe correspond to Epics in Scrum – and therefore Jira. All the practical functionalities provided in JIRA (Epic Link, Epic Name, swimlanes) are not available in SAFe.
The Essential SAFe configuration manages the first three levels of requests quite well, however it is only the first step in the much larger scope of SAFe. The next level is the Large Solution Level, which incorporates the roles, artifacts and processes required for more complex solutions. Evidently, this level demands different issues and authorizations.
For example, we could add a Large project which would aggregate all the Capabilities. However the associated Features would then be created in this project and then moved or copied in the corresponding PROGRAM projects, which significantly increases the weight and management of the different elements.
JIRA Portfolio: Is it the solution?
Jira Portfolio is an Atlassian product used to plan and manage tasks with a project portfolio, thus facilitating the division of work between teams.
One of the main benefits of Portfolio is that it provides hierarchy for the different types of issues. If we refer back to SAFe, we can classify the issues in the proper order:
We can quickly understand the benefits of this functionality that permits a visualization of the issues’ cascade – allowing us to easily see how they are grouped.
Teams as a fluid entity
In contrast to people being assigned to groups as discussed earlier, teams within Portfolio provide a more interesting solution, as people’s skills and availability are dynamic. By crossing these elements, you can create an optimized team and define the pace in relation to the attributed Features.
A plan for each ART
Again how things are categorized between SAFe and Jira can cause some confusion. An ART in SAFe corresponds to a plan in JIRA Portfolio. A plan is an aggregation of Jira issues which can be found on several project. These plans allow a user to aggregate issue data on different projects (versions, components, etc.) and integrate them into one space.
The RTE (Release Train Engineer) can then modify all the data as he wishes and plan the work of the teams over several weeks. The changes are not immediately visible to the other teams, but rather must be validated in order for it to be reported in JIRA.
As such, the planning can accumulate issues which do not yet exist in Jira to assist in planning ahead. This permits the Product Owner to have oversight of which issues are already integrated into JIRA while likewise taking into consideration information on impending operational progress.
A Program for each Solution Train and Value Stream
A JIRA Portfolio program is a collection of plans. They allow to obtain a higher level vision of the various projects in progress. Here, it is possible to leverage this notion with those of the Value Stream and Solution Train. The aggregated set of Programs (SAFe) will allow the STE (Solution Train Engineer) and the Portfolio Manager to have a global vision over the Capabilities and Epics’ progress within the different ARTs and integrate the future functionalities – without affecting the current work in production.
To infinity and beyond!
It’s true that the above is a bit of a feat to put into place, even beyond the administration and configuration. Yet if your enterprise needs to, you can expand upon the notion of a program in Jira Portfolio by aggregating several programs. This brings us to the highest level of SAFe: the Portfolio Level (which should not be confused with the name of the Atlassian product).
SAFe is a complex subject, but then again that’s a given when you’re facing the challenge of how to manage and remain in control over large enterprise development teams. If you need a hand with how to put this perplexing methodology into practice, reach out to Valiantys and we’ll help you manage your teamwork and tools.