Scaled agile framework: levels of implementation

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.