Blog

Scaled agile framework: levels of implementation

The 3-Level SAFe is implemented at the following levels: team, program and portfolio. Let’s focus on each of them focusing on what is relevant for the software tester involved.
27 March 2017
Agile
Quality assurance
Article by Vitaly Prus
Head of testing department at a1qa

We started talking about Scaled Agile Framework that helps to apply agile methodology across large development teams. SAFe is usually implemented on three levels. 4-Level SAFe is applied when there are hundreds of practitioners involved.

As for us, we’ve been working with 3-Level SAFe and will talk about it.

The 3-Level SAFe is implemented at the following levels: team, program and portfolio. Let’s focus on each of them focusing on what is relevant specifically for QA consulting practice and software testers involved.

Portfolio level

We’ll start with the portfolio level, which is the highest level of concern in SAFe and is the scope of responsibility of the organization’s management staff.

A portfolio is a number of value streams. Value streams budgeting and implementation is discussed at the portfolio level. A Backlog with Business Epics is generated at this level. Software testing and developing teams have nothing to do here so we won’t dwell on it a lot.

Team level

At the team level we deal with traditional agile teams and Scrum processes many of you are aware of. There is a backlog with user stories. When planning a sprint, teams define work and efforts necessary to meet their sprint obligations. Once the two-week sprint is over, the team meets for Sprint Review, or Demo, and demonstrates some scope of functioning software that can be released. Daily meeting also take place.

At the end of every iteration agile teams meet for Iteration Retrospective where they discuss what has been done well, what has not and what ways for improvement can be found. It’s worth mentioning, that developers and QA work side by side to deliver working software of the release quality. As you see, the process is the same as it’s in Scrum. The difference is that the sprint duration is restricted to 2 weeks.

Program level

The program level is where most of the SAFe differences from Scrum lie. First of all, the size of the development team is larger. The whole team is made up of the usual sprint teams that are applied to the ongoing development mission. The whole team in SAFe is called Team of Teams and can be composed of 50-125 specialists.

The goal of the team is to deliver a Potentially Shippable Increment. “Potentially Shippable” is about the quality of the software, not its marketability. It should be free of defects and possess release quality. PSI is delivered during five sprints.

With every next PSI, end product gets more value. Value in SAFe is delivered by Agile Release Trains (ARTs), which is one of the center concepts in SAFe. The more products are delivered at the organization, the more ARTs there will be. In our project there was only one release train.

ARTs: why such a metaphor? Let us make it clear.

Imagine that you are the customer and you have to get from Prague to Moscow by plane. To reach the final destination, you’ll have to tackle some risks and restrictions. You have to choose between the offered data options and align your timetable. You also have to purchase the flight ticket in advance and book a place on the plane.

A plane is said to be the most convenient means of transportation, but it isn’t free of risks either. The luggage can be lost, the flight can be delayed. Of course, it will take time to overcome any of them. In brief, you can’t be sure that you’ll reach the destination when you’ve planned to. This is exactly what stakeholders feel when the product is developed incrementally.

Now let’s imagine another situation. You travel by metro and have to get from one end station on line to the other. You go underground, buy a ticket and take a train. You don’t have to make any preparations beforehand and you are sure that you’ll get to the required station at the time needed because trains come and go regularly. Having missed one train, you’ll take another one in a couple of minutes.

The latest example describes the ARTs’ work perfectly well.

They deliver value regularly (cycles of 5 sprints). As a result, it becomes easier to explain the stakeholders that features that haven’t been implemented in this sprint, will be implemented in the next one. The development process gets more predictability and the product development lifecycle shrinks. The customer should be calm and satisfied as s/he is aware that the release deadline won’t be missed and the end product will look like it was intended to.

So these are the basics of each level in SAFe viewed by the QA team. Next week we’ll answer the question: what are the key differences in product development in Scrum and in SAFe?

If you have any questions left, drop us a line in comments.

More Posts

QA for financial applications: 4 reasons why it is a must-have
17 November 2024,
by a1qa
5 min read
QA for financial applications: 5 reasons why it is a must-have
Striving to release high-quality financial apps? Read on and discover 5 core reasons why your eBanking and financial solutions need software testing.
QA consulting
Quality assurance
Test automation
Why do bugs get missed
27 September 2024,
by a1qa
7 min read
Why do bugs get missed? Learn the problems and tips to avoid them
Still, finding overlooked bugs after the app goes live? Let’s find out why this happens and how to fix it.
Performance testing
QA consulting
Quality assurance
Test automation
Soft skills 101
13 September 2024,
by a1qa
4 min read
Soft skills 101: how to supercharge business success in 2025
Discover the value of soft skills for both career development and workplace improvement and learn some tips to sharpen them.
General
Quality assurance
QA to ensure smooth migration to the cloud
15 August 2024,
by a1qa
3 min read
QA to ensure smooth migration to the cloud
Learn how effectively migrate to the cloud by implementing QA activities.
Functional testing
General
Migration testing
Performance testing
Quality assurance
Test automation
Load testing
23 July 2024,
by a1qa
3 min read
7 reasons why businesses need load testing 
Want to optimize software performance or ensure its smooth functioning during peak sales season? Discover how load testing may help.
Quality assurance
Test automation
27 June 2024,
by a1qa
3 min read
Establishing seamless interaction between development and QA teams to boost productivity
Establishing seamless interaction between development and QA teams to boost productivity
Agile
General
Quality assurance
Test automation
17 June 2024,
by a1qa
5 min read
Shifting to test automation to maximize software quality
Explore in the article why businesses should move from manual testing to test automation.
Quality assurance
Test automation
RPA in QA
28 May 2024,
by a1qa
4 min read
Embracing robotic process automation to drive efficiency in QA
Discover how the convergence of robotic process automation helps reshape software testing practices.
General
Quality assurance
Test automation
QA for fintech
7 May 2024,
by a1qa
5 min read
Navigating the fintech frontier in 2024: QA’s role in delivering high-quality financial software 
Unveil the future of fintech innovations and learn to refine their quality with the help of software testing.
Blockchain app testing
Cybersecurity testing
Quality assurance

Get in touch

Please fill in the required field.
Email address seems invalid.
Please fill in the required field.
We use cookies on our website to improve its functionality and to enhance your user experience. We also use cookies for analytics. If you continue to browse this website, we will assume you agree that we can place cookies on your device. For more details, please read our Privacy and Cookies Policy.