Jira Software is the market leader among tools for software development by agile teams.
In today’s blog post, we’ll take a look at how to leverage the strengths of Jira Software to scale agile principles.
We will focus on one of the most popular frameworks – Scaled Agile Framework (SAFe).
SAFe in a nutshell
SAFe® is an acronym derived from Scaled Agile Framework®. At its core, it is a set of
- best practices,
- rules,
- integratable principles
- and competency definitions.
SAFe is being developed as a product of a registered company, Scaled Agile, Inc..
Its first release was in 2011. Since then, this product has evolved evolutionarily, with the current version being 5.1 (previous versions: 1.0, 2.0, 3.0/LSE, 4.0, 4.5, 4.6 and 5.0).
SAFe is targeted at transforming larger enterprises towards methodologies such as Agile, Lean and DevOps.
Leveraging the principles of these methodologies enables enterprises to execute a rapid and effective response to changing market conditions, sudden changes in customer needs, or the rise of new technologies.
SAFe helps deliver products, services and solutions efficiently.
Several case studies from large and small enterprises confirm its strengths. These include:
- 20-50% increase in productivity
- Improved quality by 25 – 75%
- Reduction of solution delivery time by 30 – 75%
- increase employee engagement and satisfaction by 10 – 50%
Because it is a scalable and configurable framework, businesses can customize it to reflect their needs, habits and company culture.
4 standard configurations are described:
- Essential SAFe (The simplest configuration that provides the main benefits. It incorporates the minimum elements needed to successfully practice SAFe.)
- Large Solution SAFe (Covers the development of larger complex solutions.)
- Portfolio SAFe (Compared to Large Solution, additionally describes the portfolio level – its strategic management, financing, etc.)
- Full SAFe (Full and comprehensive configuration. It is targeted for the development of large complex integrated solutions that need to be managed and require the collaboration of hundreds of employees.)
As can be seen, SAFe can be practiced by a few interested employees or up to hundreds of employees.
It is good to keep in mind that SAFe is a framework, i.e. it does not strictly force you to adopt to the dot all the described principles and rules.
SAFe is aimed at solving problems arising from scaling beyond the boundaries of a single team.
Agile methods (Scrum, Kanban, etc.) focus only on individual teams. The goal of SAFe is to synchronize the collaboration and outputs of these individual teams.
Of course, SAFe is not the only framework that describes solutions to these problems. Other well-known alternatives are, for example:
- DAD (Disciplined agile delivery)
- LeSS (Large-scale Scrum)
- Nexus
When to use SAFe?
Deploying SAFe is not just about deploying a tool that records work.
It’s a change that requires employees to think in the direction of Lean/Agile principles. Understanding these methodologies is essential early in the transformation process.
Key employees should be motivated to apply agile principles, consistently across projects and portfolios.
When to consider transformation?
- When teams want to perform assigned work autonomously, independently.
- When multiple teams are already using Agile practices (mostly Scrum), but their deliverables are often delayed due to another team blocking their work.
- When the goal is to scale Agile practices across the enterprise but it is not entirely clear which roles need to change and how.
- When there is a need to increase productivity and reduce time to deliver solutions.
- When you encounter a number of technical or business dependencies during solution development, or when there is complex collaborative coordination involved.
- When the enterprise is large or when developing complex solutions that require multiple teams to collaborate.
- When the enterprise has reached a tipping point:
- “A burning platform” – The enterprise has difficulty being competitive and it is problematic to reverse this state fast enough.
- “Visionary leadership” – The business wants to take proactive actions to secure a better market position in the future.
Several corporations identified the deployment of SAFe as one of the biggest challenges, but also added that it has delivered a number of benefits, which has been a well-deserved reward.
Jira Software capabilities in the context of SAFe
Jira Software by default immediately after installation:
- Includes a template for a Scrum-driven project (or Kanban, Kanplan), which includes
- backlog – for prioritizing and planning tasks
- Kanban board – for managing active sprint tasks
- Epic → Story → Sub-task hierarchy – for work breakdown
- metrics and reporting (e.g. Burndown chart or velocity chart) – for retrospective purposes
- Allows you to link Jira tasks using bindings and thus keep track of their dependencies.
- In general, it allows you to track any unit of work – record its status and further describe or categorize it in detail using any attributes or additional configuration that may have been created.
This standard functionality partly covers the lowest level in SAFe, the so-called Essential level. Here it is, among other things, about managing the work within individual teams and synchronizing their outputs in order to integrate partial solutions into the overall work.
Also, various sub-standard Jira functionality is used in the higher two levels – in the so-called Large solution level and Portfolio level.
Examples are the use of Kanban boards for managing the so-called Portfolio or Solution backlog, or the registration of strategic topics as individual Jira tasks and so on.
However, in order to fully cover the needs of SAFe in Jira Software, its full potential must be used, namely:
- Jira’s flexibility and its configurability. It is about adapting standard settings in order to adapt to the specific needs of SAFe and the needs of the business. As an example, we can mention the adaptation of workflows, attributes, access rights or notifications.
- Extensibility of Jira. This involves the installation of modules referred to as Jira apps from the Atlassian Marketplace platform. This can bring a large amount of new, necessary functionality to the Jira tool. Specific examples are shown below.
An example from practice
The client was undergoing an agile transformation. He preferred a solution built on the Jira platform because of its speed of deployment and flexibility, as he gradually plans to make Jira a central tool for managing and recording the work of employees.
Our client also appreciated the ease of use and modern UI of the Jira tool. Jira’s modularity and extensibility were also strengths that made Jira stand out in the tool selection process. The ease of upgrading to higher versions was also a desired feature, which Jira fulfills to a tee.
Last but not least, Jira can be natively integrated with the Confluence tool. Confluence is a documentation/wiki tool from Atlassian.
While deploying and implementing SAFe principles into the Jira tool for one of our clients, we addressed the following challenges, among others:
Multi-level task hierarchy
In order to visualize the hierarchy of tasks, practically from the highest level to the lowest, we reached for the Jira application Structure.
This way, one can get an overview of the breakdown of management initiatives down to individual tasks for developers and the like.
The Structure allows you to build and display a hierarchy of Jira issues based on different rules, we built the issue hierarchy based on Issue Links.
Another great advantage is the ability to also display different attributes and even edit them directly from a given view. Last but not least, Structure can aggregate attribute values upwards, which is very handy when analyzing time worked or estimates at higher levels.
Terminology vs. functionality
In order not to make this point unnecessarily complicated, it is as follows: From a SAFe perspective, it would be better if the standard entity in Jira Epic was called Feature. However, Jira does not allow renaming this entity by default.
It is true that many new Jira task types can be created in Jira, so it would seem that you could just create a new task type called Feature.
While this may seem like a good solution, it does not carry over the specific Jira functionality that is tied to Epic. And this functionality would fit exactly into the needs of working with Feature.
However, there is a very elegant solution. It is the Jira application SAFe EPIC to Feature Translator for Jira, which will show users “Feature” instead of “Epic”. Technically, however, Epic is still Epic in the background and therefore all standard functionality or compatibility with other Jira applications is preserved.
Managing management initiatives
Management of management initiatives, i.e. how to record, prioritize and plan them, was covered by standard Jira Software functionality – we created a Kanban board.
This Kanban board contains all initiatives – they are Jira tasks of a specific type that have the necessary attributes. An example would be the attribute used for scheduling – Program Increment.
One look at such a board and it is immediately clear which initiative is at which stage of its life cycle and which initiatives are the most important.
Program Increment Planning Board (PI Planning event)
The PI Planning event, i.e. Program Increment Planning, is essential if we want to synchronize the collaboration and outputs of multiple agile teams.
A very useful helper at this event is the PI Planning Board. This is a board where scheduled tasks for each team, each iteration and, last but not least, dependencies can be seen here. It can look something like this:
However, Jira Software does not include the necessary visualization for such a dashboard in the standard configuration. That’s why we reached for Jira’s BigPicture application (together with BigPicture Enterprise).
BigPicture includes a module that perfectly meets the needs of program increment planning.
This module allows you to display the teams collaborating on a given solution on the rows, the selected number of iterations on the columns, and the cards representing the tasks scheduled for a given iteration for a given team in the individual cells.
It also visualizes the dependencies between tasks – in red, green or grey (see arrows in the image above). Depending on whether there is a scheduling conflict or not (e.g. task A must be completed before task B but they were scheduled in iterations in reverse…), the link will be shown in green or red.
Even this module contains a section for the so called program backlog – all tasks that have not been scheduled yet are accumulated here.
Different solutions and approaches
Just as there are different alternatives to SAFe, there are also different approaches to implementing SAFe in Jira. The approaches we applied as described above are just one of them.
Different solutions are described by some of the more prominent authors of Jira applications:
We have noticed that although the solutions vary, they often use a combination of existing Jira applications, for example:
For completeness of information, there is also a solution from Atlassian – Jira Align (formerly known as AgileCraft).
In the same breath, however, we should add that this solution is currently used by a smaller number of very large corporations, built on top of multiple Jira instances.
Interested in this topic? Would you like to learn more?
If you need help from experts with the implementation of SAFe in Jira, or advice on how to use it most efficiently in your company, do not hesitate to contact us
Our Atlassian solutions
Samuel Titka
Atlassian consultant
Resources and other useful information:
