a1qa blog

QA core for executives

How our QA team scaled Agile: SAFe overview

Read how our QA team had to replace Scrum principles with those of SAFe (Scaled Agile Framework) upon the customer’s requests and how we managed to achieve win-win results.

The a1qa acquaintance with SAFe started two years ago. A customer, who has been cooperating with us in QA outsourcing for more than 4 years, confronted us with the fact: “As of today, we start working with SAFe, guys.”

However, we had no other options but to obey. We learned the basics, read numerous hands-on articles and started tuning our processes. Looking ahead, we must admit that we did it quite successfully.

To date, we’ve been working with SAFe for almost two years. And our experience is what we want to share. Hopefully, we’ll foretell some of the difficulties that your QA team may come across.

Let’s start with some basics.

When apply SAFe?

Google displayed us the following big picture:

Agile: SAFe methodology

The core thesis about SAFe is that it contains a number of rules and regulations to ensure smooth agile scaling in a large number of development teams.

  • Are there multiple software products developed and roles in the project?
  • Do you need dozens of approvals to put in place any new suggestion?
  • Are there many development teams who are eager to apply the lean-agile approach?

If the answers are “yes” than SAFe is what can be of help.

What are the levels in SAFe?

SAFe basic structure contains three or four levels depending on the specific needs of the company. They are portfolio, program and team levels. The 4.0 SAFe that has arrived this January has introduced the fourth optional level, called the Value Stream that should be applied in companies with over 120 people working on heavy software systems. In teams of 50-125 people (as it was in our case) the three-level structure is more convenient.

To gain a better understanding of every level, let’s take an example of the project and focus on its levels. It’s important to note that the levels will be analyzed from the QA team’s point of view, not the business one.

Let’s imagine that we have to enhance the e-commerce application aimed at selling books. The current functionality of the app is very simple: the customer uses the search bar to find the book he or she needs and orders it. When the book arrives at the warehouse, manager notifies the customer and he/she collects it from the warehouse. Apparently, the app is too simple to be competitive on the market. We need to strengthen it adding some more features that will make it more attractive.

The portfolio level is the highest level of concern in SAFe. The responsibility of the portfolio level is to discover major initiatives (business epics) that would reflect business priorities. Epics can be functional and architectural by nature.

As for our website, the functional epics shall be the following:

  1. Organize delivery across the country with the opportunity to follow order processing in a user’s account.
  2. Develop an online communication platform for books amateurs.

Architecture epics should be the following:

  1. Integration with GIS (geographic information system).
  2. System migration to the cloud.

Example of SAFe number one

So far it’s pretty easy, we hope. Now we are going down to the program level.

Program level is where business epics are split into features and development team and other resources work on the implementation of the features. A feature is a part of the product that should give some flow of value to the customer or to business.

Let’s split one of the epics on the team’s level. Online communication platform epic can be subdivided into the following features: user’s account, forum, and private messages.

Example of SAFe number two

On the team level, every feature shall be reformulated into clear and short user stories that can be estimated and implemented within a sprint.

For instance, private messages feature can be broken down into the following user stories: send messages and get messages and save chat history options. Architecture epics have to be broken down as well.

Example of SAFe number three

In such a manner, with every next level, the tasks get smaller in size and their boarder lines are specified. Estimation also gets more accurate.

In the next article, you’ll learn the workflow specifics on each of the SAFe levels.

Share this:

QA news and tips delivered right to your inbox
We’ll send you one newsletter a month, jam-packed with amazing QA offers, hottest industry news, and all kinds of Software Testing goodness.