Skip to main content

5 min read

Project Management Methodologies and the Atlassian Toolset, Part 2

Selena Cass
Selena Cass
14 November 19 Agile
Project Management Methodologies and the Atlassian Toolset, Part 2
alert2 Icon
The content of this blog is no longer updated

Project Management Methodologies and the Atlassian Toolset, Part 2

In this multi-part series, we explore the evolution of project management methodologies with a software focus, and provide a bit of guidance around configuring your Atlassian stack to implement them. Contributing to this article are Adaptavist’s Jon Kern, co-author of the Manifesto for Agile Software Development, and Project Manager Alaistair Wilkinson. Here in Part Two we'll discuss some of the scaled Agile frameworks that have been developed since the publication of the Agile Manifesto.

Let's pick up from where part one of this series left off: the dawn of the age of Agile. Once Agile adoption had taken off in smaller teams and companies, it was only natural for larger organisations to take interest in the efficiencies and lower rates of failure that this new way of working could bring. Soon they too began to jump into the game. But in order to harness Agile at enterprise scale, an approach was necessary that could work in a vastly different environment than the small teams targeted by the Agile Manifesto and Scrum guide.

Larger organisations need to address cross-team schedules, dependencies, and risks, so methods like LeSS, DAD, SAFe®, Nexus, and Scrum@Scale were born to address them. Such techniques have continued to gain popularity in today's enterprises.

If your organisation is exploring scaled agile frameworks, you might be wondering if they can be supported in Atlassian Jira (which your agile delivery teams likely already use). The good news is that with a little bit of pragmatic decision making, configuration, and carefully selected apps, they most certainly can!

Scaling Scrum with Nexus and Scrum@Scale

If we level up Scrum to a maximum of nine teams, we can implement a program called Nexus. Nexus bears more than a passing similarity to Scrum-of-Scrums, as a selected group of individuals runs a routine secondary team dedicated to clearing blockers and integrating cross-team deliverables.

If your teams are Jira-literate and have access to a lightweight automation tool (we're fans of Autoblocks for obvious reasons), running Nexus can be very light in terms of configuration. Each team has a Jira project, and the Nexus team rolls everything up onto a board.

Another add-on app we might consider here (and in most other scaled Scrum implementations) is User Story Maps, by Easy Agile. This plugin lets us see how the different stories at play are interacting with our epics across sprints and can be useful as a Nexus team looks to the future.

Scrum@Scale is another Scrum-focused methodology that seeks to apply Scrum across teams and levels in the business, resulting in a minimum viable bureaucracy controlling a "scale-free" organisation. The teams work at their respective tasks, and there are Scrum of Scrums, Scrum of Scrum of Scrums, and lastly, the Executive Action Team that manages a transformation backlog and has the responsibility to remove impediments that cannot be solved at lower levels.

The Scrum@Scale framework allows for more teams than Nexus, and the roadmap to implement it is a little less daunting than the frameworks that follow here. Using Jira to track Scrum@Scale calls on the apps we've suggested before, but no complex configuration otherwise.

Adaptavist Heirarchy Wall white

LeSS is more

Speaking of complexity, suppose a large organisation decided to take forceful measures to destroy silos and flatten the hierarchies that impede application of Agile methodologies. Maybe implementing LeSS, Large-Scale Scrum, would be considered. At its heart LeSS is a huge cultural and structural shift, as managers become mentors, teams are empowered to self-organise, and individuals are trusted to collaborate and forge new ways of working.

The ideal implementation for LeSS would be for there to be one product owner and backlog which scrum teams can tackle in synchronised sprints. Sprint planning would have two sections: one where teams would combine to define what would be delivered overall in the coming sprint, and then a second where the teams would break away for traditional sprint planning.

During all the cultural shifting that is taking place during the transformation into a LeSS organization, Jira Software's inherent flexibility shines as it's able to be configured quickly to reflect the team's immediate needs while still providing useful reporting.

LeSS methodology dives deep into Lean thinking and requires a significant shift in mindset – a journey in and of itself, and a topic we tackle in other posts.

Don't forget DAD

Next we'll look at DAD, or Disciplined Agile Delivery. DAD recommends using existing lean and agile techniques, and flows them outward to encompass the entire organisation. DAD is known for having an organic, supportive path for businesses that want to evolve to become Disciplined Agile Enterprises.

There are steps/process goals that radiate from the Scrum Team level, encompassing growing numbers of business units and process until the enterprise is aligned. DAD recognises that a Scrum Team may not really have all of the roles in it needed to release a product or program increment, and therefore identifies secondary roles (integrators, SMEs, and so on) that complement the Scrum team.

DAD brings in a DevOps layer to support the groups doing the coding, and therefore if we're going to do DAD in Jira, it's crucial that our ducks are in a row. For effective DAD implementation, we recommend using ALM Works Structure, along with the other tools mentioned already, to keep the different levels aligned and output value visible.

safe header banner

In SAFe® hands

Lastly, let's review the Scaled Agile Framework for Enterprise® (SAFe®). You may have already seen our whitepaper on the topic, where we dive deep into a pragmatic implementation of the framework using Atlassian tools.

In short, SAFe® aligns multiple teams of up to 150 people each in an Agile Release Train, with a focus on delivering value in concert. While the teams are working in traditional two-week sprints, an interval of eight to twelve weeks comprises a larger Program Increment (PI). A PI starts with a PI Planning event that is attended by all teams and ends with an Innovation and Planning sprint designed to work on structural capabilities and defects, with the product-focused work following.

Once there are multiple Release Trains needed, then Large Solution and ultimately Portfolio levels can be combined into a 'Full SAFe®' structure. Adaptavist's pragmatic core solution for SAFe® in Jira uses all of the apps we've mentioned already in this post, along with some SAFe®-specific configuration.

The beauty of doing SAFe® with Jira and Confluence solution is that it is adaptable! The best framework for scaling agile in an organisation after all, is the individual one that meets the special cultural, process, and tooling needs and constraints of the company implementing it.

Custom fit is the right fit

The size and structure of an organisation, its current processes and ways of working, and its cultural make up are the most critical aspects in deciding what framework is right for tackling Agile at scale. Every one of the techniques discussed here has pros and cons, and there is no single one that will be a perfect fit for any team.

Adaptavist always advocates taking a pragmatic approach to change in any organisation. Address the biggest pain first to deliver maximum value early, and iterate as you go, learning and improving as both new ideas and new constraints emerge.

Looking for a partner to help you increase agility in your complex organisation?


copy_text Icon