Scaling Agile with Atlassian and SAFe

Atlassian has been supporting large companies as they adopt agile methodologies for years. We’ve seen that while many scaling methodologies are available, the Scaled Agile Framework (SAFe®) has been the most widely adopted.

Join this webinar to learn one approach to supporting SAFe® with Atlassian products as explained by an Atlassian agile coach and solutions engineers from Cprime. They’ll walk through a SAFe® overview and a step-by-step tutorial on how to use JIRA Software, Portfolio for JIRA and Confluence in a SAFe® environment.

There will also be a live Q&A section after their presentation, so please come with questions on how these tools and SAFe® can support organizational needs at all levels.

View the Presentation Below:

Talk to our experts about scaling agile in atlassian

Executive Summary (Transcript)

Today, we’re going to be talking about three major topics. First, we’re going to start with team level agility. Second, we’re going to give a quick overview of SAFe and then lastly, we’re going to focus quite a bit of time on the tool requirements from the Atlassian side on implementing SAFe with our solution.

Let’s jump right into team level Agile, so if you’re attending this webinar, you’re probably very familiar with Scrum, with Agile and Lean but the irony with Agile really is that most people don’t get it. To make matters worse, they really think they do.

This is the point in your journey where you need to take a deep breath and really understand what is it that you’re trying to do and how are your teams working together to deliver it. If one team does Agile really well, chances are other teams in your organization do it very differently.

Let’s begin to understand what questions each of your teams as you’re moving towards a SAFe roll out.

First, let’s start with planning. Talk to your teams and understand what’s working. Have the team talk to you how they’re using Jira to do planning.

You can see on the right-hand side, I’ve got plan mode with Jira Software. You’ll want to ask each of your teams how they’re using epics, versions and prints, as we often see variability from team to team and customer to customer.

Once you feel comfortable with a planning culture across your organization, let’s shift to release. Releasing is the hallmark of any Agile team. How often does the team release? What metrics do the teams use to assess release health?

Once the team releases, let’s talk about the retrospectives. Retrospectives help teams understand what’s working and what’s not working within their process. As you scale Agile, it becomes, more important to share learning’s from retrospectives across multiple teams, so that the organization can move forward as a whole.

Next, let’s talk about team level velocity. Velocity is the amount of work a team can complete in any given iteration, so in Jira Software’s Velocity Report, the most obvious question to ask is does the team have a consistent or predictable velocity as they’re contributing to the overall company goals?

As teams’ forecast and actual delivery becomes more and more divergent, it becomes harder to forecast how much work the organization can do company wide rather than any individual team, so I would focus on understanding why velocity is erratic at any given team as a top priority item.

How do we do that? Let’s say you find a team that’s struggling with having a predictable velocity. The next step really is drilling down and understanding why. The Sprint Burn down Report really helps break the mechanics of the sprint into its component parts, so if we look at the chart in the upper left-hand corner, we see two lines. A grey line, which represents the ideal burn down and the red line, which indicates what actually happened. As the line moves to the right, that indicates the passage of time and as the line moves down, that’s reflective of the team completing work.

If we look at this team, we can see that they’re generally following the burn down and we would say that this is a successful sprint. We can see at the bottom, the amount of work they completed and any issues that got removed from the sprint.

Things to watch out for here are if the red line moves up, that means somebody added new issues to the sprint, which invalidates the sprint forecast. We see this as a very negative anti-pattern for teams.

Also, if the red line moves significantly to the right without dropping, meaning the team is not incrementally delivering work and the team should look for ways to ship particular stories during their sprint earlier rather than waiting until the end and crashing all of their stories out at the last day or two and this report can be very myopic, as you’re looking sprint to sprint, so remember to jump up a bit and look across sprint rather than focusing on an issue that came up in one particular sprint.

Once we understand how the overall sprints are going from iteration to iteration, oftentimes teams will ask, “Well, what can I do to improve actual story delivery?” The control chart highlights how reliable the team is at delivering stories over time, so we can see the red line is the average amount of time it takes to deliver a story and in this case, it’s between two and a half and three days but the blue line is the overall rolling average, so we can see the team is getting more efficient over time and the shaded area is the predictability of the team, so more shading means the team is less predictable.

If you really want to help tune the team’s estimation culture, what you can do is highlight all of, say, the story point values of five over the past three months and then you can see how predictable the team is at delivering those stories.

If there’s lots of blue shading, chances are you need an estimation tune-up. If the lines are very narrow and level, you’re doing really well, so once the actual story delivery and sprint velocity stabilizes, the next thing to look at is how the teams work together at delivering larger bodies of work.

Epics, as you know, are larger features that are composed of several stories and releases are actual pieces of software that get delivered to customers, so if we take a look at this report, we can see the burn down of a particular epic over town.

The blue work is the amount of work remaining, the dark blue work is any additional scope a product owner added and the green is the amount of work the team actually delivered to that epic.

We see a very natural burn down here, which is indicative of a health team, so as you make that transition to scaling Agile, look at a number of epics or a number of releases across your teams and see, are we doing the right thing? Are we working together efficiently and are all of these items shipping on time or do we have challenges with delivery or scope creep during the evolution of these epics and releases?

If you’re a scrum team, you probably know that sprint planning, sprint review, stand up and sprint retrospectives are core to the team’s overall health and delivery.

At Atlassian, we’ve done four great blog posts about how we do these four ceremonies and have tips and tricks to help your teams get the most out of these scrum ceremonies.

Lastly, I want to close with the Agile Coach. The Agile Coach is our overall resource that talks all things Agile, whether you’re a developer, a scrum master, a product owner or an executive sponsor. Chances are, you’ll learn something by visiting our site and learning how to scale Agile at the team and organizational levels.

Once your team really tunes how they do Agile, that’s a moment to celebrate. Getting a number of teams with a healthy Agile process, working together at an organic level, is something that’s really, really worth celebrating and as you know, the post-it note is a hallmark of Agile teams and once you begin scaling Agile, things can get complex really quickly.