The Simplest Way to Run SAFe with JIRA
May 8, 2018, 10:15 AM
So you want to use JIRA in your SAFe-going organization? There are plenty of design decisions to get right before you’re good to go.
“Going agile with JIRA often looks like learning to sail with a ship you’ve built yourself – in a bottle” – Dr. Agilefant, 2016
Somewhere in your large, complex organization there are people who think you should strive for a more agile way of working. Some of those people may think that the Scaled Agile Framework (SAFe™) could be a good blueprint to follow.
While there are alternatives, let’s suppose you want or have to use your existing JIRA to support also the new way of working. Read on to see the challenges involved and one possible solution to achieve that!
Mismatch of models
SAFe is less complicated than it may seem at a first glance. The difficulties stem from JIRA’s conceptual model, which does not match what is suggested by SAFe. On top of that your organizational design and/or constraints posed by your suppliers or customers probably do not match the set-up suggested by SAFe either, but that is the subject of another post.
JIRA natively has a three level requirements abstraction model (Epics, Stories and Sub-Tasks), but the terms are not configurable. Sure, you could define new issue types with the proper naming, but the terms in the UI will remain the same. This means that at least some mental mapping is required from the users. And of course, a three-level work item breakdown does not scale to a four-level SAFe.
In addition, JIRA’s single level non-nested work containers (Projects) means that at least some workarounds will be needed to express SAFe’s levels of planning.
JIRA originated as an in-house bug tracker. It’s first commercial release was in 2002, and while plenty of features have since been added, little has been taken out. While this makes JIRA highly configurable, it is easy to go overboard in terms of the workarounds.
A common pitfall we’ve seen is that prevailing impediments to agile such as a function or system based organization are replicated into JIRA as some key concept - typically as Projects. This further cements the existing structures – which in most cases should be dismantled and rebuilt around customer value delivery.
Another common challenge stems from attempting to overcome the limits of JIRA with plug-ins. While this is possible – to a degree – it leads to a more complicated set-up. And even with a willing, SAFe-trained organization and detailed instructions, the supposed way to use JIRA can prove too complex to grasp.
The result is a constant demand for training to grasp the complicated JIRA-with-plugins set-up. People also simply go around the complicatedness and make up their own special ways of using the tools. This makes progress roll-ups difficult and improving the ways of working via measurements impossible.
Resorting to ‘shadow accounting with MS Excel’ is also fairly common solution even in cases where JIRA is seemingly being used.
The simplest way
In matching SAFe and JIRA, you have to make some compromises. You should strive to avoid design decisions that directly get in the way of the transformation. You don’t want to simultaneously deal with both the resistance to the new way of working and the complicatedness of the desired JIRA usage model.
Having observed JIRA usage in a number of organizations striving toward large-scale agile we have devised a blueprint for how to implement ‘three-level’ SAFe (known as ‘Portfolio SAFe’ in the 4.5.1 version) using JIRA.
We’ve deliberately aimed at the simplest possible model doable with plain vanilla JIRA. While it is by no means perfect, it presents a sane starting point. The mapping of the key concepts is described in the table below.
The choices made above come with good, bad and an ugly side. The Good is what we see as the upside of the choices, and The Bad as the downsides which we see that can be overcome. The Ugly refers to those downsides which are inherent to plain vanilla JIRA and can’t easily be worked around.
- Very little mental mapping required; JIRA concepts are not forced to represent other things than their name implies
- User per party and no access restrictions support the notion of shared responsibility and promotes the importance of frequent communication
- Can be implemented to an existing JIRA set-up; changes are restricted to a single project and new ‘party’ users
- Possible with plain vanilla JIRA
- Not necessary to use JIRA’s rather convoluted sprint functionality
- Virtually non-existent licensing cost (only a handful of user seats required)
- Frees the parties to organize themselves as they wish as a team (do more detailed coordination on a physical board, work as a mob, and so on)
- Changing the legacy organization structure based around systems is a key challenge in most organizations. Modeling systems explicitly as Components can be leveraged to spot and eliminate dependencies and problems with the current organizational design
- Unconventional design choices (compared to how JIRA is in my experience commonly used) may cause resistance in moving to the model.
- No user per a living person
- However, the model does not fundamentally change if the team-user is replaced with a person-user; you can still model the teams and trains as groups and use these in queries
- No detailed user access control; everything is shared;
- While people often create separate projects to prevent others from ‘messing up their issues’, these fears are mostly unfounded; people with access rights make mistakes too and you should have frequent backups and selective restoring capabilities anyway
- No user per a living person
- To leverage strategic themes in querying lower level items, you’ll need to add them by hand all the way to the story level
- JIRAs label editor (or rather, the lack of one) makes the usage of Strategic themes error-prone
- One might argue that having ‘Bug’ as its own issue type is against the grain of ‘the simplest thing that might work’; however, our experience is that sooner or later you’ll want to be able to discern between fixing and enhancing based on work item type; this also frees using labels for other purposes
- Plain vanilla JQL is not powerful enough to support many queries which can be seen as interesting to running a SAFe-like process
- However, the most important metric of SAFe has to do with PI Objectives and those we suggest should not be in JIRA at all
- Also, the plugins required to ease the needed queries and detailed filtering work around the most critical issues are relatively inexpensive
- Hard typing of requirements and no support for N-level work item splitting and; while it’s important for proper iterative refinement and keeping the batch sizes manageable, like JIRA, few tools support this adequately
- Program boards with dependency visualization can’t be done with plain vanilla JIRA; I predict sooner or later someone will do a free plugin compatible with Cloud JIRA
Running the model
We are running a model very similar to the one described in a couple of customer cases. In the future we will be writing about for example how PI and sprint plannings work in this model, and also present a set of example queries to questions commonly asked by the key SAFe-org stakeholders (such as ‘show me all the work related to this epic’ or ‘show all the work related to this strategic theme).
To be among the first to get the link, follow Nitor on Twitter.
And should you be running something similar - or even try this model out - we’d very much like to hear of your experiences.
Jarno Vähäniitty, also known as Dr. Agilefant, has experience in lean-agile and tools for work management since 1999. Jarno has worked with tens of organizations and written the seminal Ph.D. on agile product and portfolio management in 2012. As Senior Lean Agile Coach at Nitor and advisor at Agilefant, he is enjoying the best of both worlds: transformation engagements in exciting customer cases, tools and writing.