The Scaled Agile Framework®, AKA SAFe®, has significantly increased in popularity in recent times. Agile software development methods are already part of everyday life even in large industrial companies, and there is a need for scalable processes. But why SAFe®, in particular, and what does it entail from the point of view of product management?

SAFe® Is a Detailed Model for Agile Development

Behind the popularity of SAFe®, there is exceptionally well-conducted productization (which deserves its own blog post). The model is clearly defined, so there is a great deal of support material and coaching available.

SAFe® provides development teams with flexible opportunities to choose between various methods, such as Scrum or Kanban. However, for almost everything else needed in development projects, there is a model accordant with SAFe®. The entire development process is based on an Agile Release Train (ART), which, as can be predicted, produces code efficiently. Depending on the delivery size, the model may contain different levels for value delivery, ranging from products to solutions.

In addition to the development process, SAFe® also defines the responsibilities connected with software development. At the lowest, i.e., Team Level, the familiar roles of agile development (e.g., Scrum Master, Product Owner, and Development Team) apply.

The Program Level combines the output of the teams with the Agile Release Train, for which a Release Train Engineer (RTE) is responsible. The RTE is responsible for the “general project manager work,” meaning that their primary task is to ensure that the Agile Release Train arrives at the station on time. Product managers, and possibly also the architects responsible for the delivery content, work in collaboration with the RTE.

Depending on the size and complexity of the organization, there can be one or more additional levels which combine the content of the various ARTs into larger delivery entities (Value Streams, Solutions). When it comes to the division of labor, the same principle, however, applies to each layer: the architect owns the technical implementation, the product management defines the content, and the “project manager” is responsible for ensuring the realization of the plans.

For the part of the content and the schedule, these three are the key roles, although of course SAFe® does also define other roles, varying from business owners to UI designers and testers.

SAFe® and Product Management

SAFe® determines how software development works, so, theoretically, it can be used in both the product and project business. If the work purely aims at customer delivery, the Product Owner speaks for the customer and is responsible for the requirements in the same way as with, e.g., Scrum.

Most industrial companies have already realized that it is also advisable to manage and reuse software in connection with project deliveries. At the same time the requirements of, e.g., the IoT solutions have created needs like interface standardization. Standardized components then require life-cycle thinking, requirements management, and other product management components.

In practice, SAFe® is usually used as a software development model for products or productized services. The part of the product”™s life-cycle management that takes place before the development decision is made or after the software is published is mainly excluded from SAFe®.

SAFe® Does Not Take a Position on Requirement Sources

Traditional software development may have been thought of as a “factory” into which requirements are fed and from which software comes out. Even though viewing software development as a “factory” does not do justice to a functional organization, it still reminds us of the basic laws which also apply when using SAFe®.

1. Bad or unnecessary requirements cannot create good business.
2. If too much material is fed into the “factory,” the production slows down.
3. The more finely the feed (the requirements) is broken down, the more quickly the product is completed and starts to deliver value.

SAFe® defines a variety of practices, familiar from agile development methods, which help to overcome the challenges connected with traditional software development. Despite those, however, the role of product management is still clear: the most important task of the product manager is ensuring customer value.

In SAFe®, the requirements of the highest level are called Epics, and they are managed with the Portfolio Kanban.

The first column on the board is a Funnel, i.e., the beginning of the traditional idea funnel. Some gather all requirements in it, whereas others manage the idea level in some other tool from which the best and most important ideas will be imported into the Portfolio Kanban.

Review, i.e., the second step of Kanban, is often the most difficult. The value delivered with the Epic is described and defined in it.  SAFe® recommends that the Weighted Shortest Job First method be used in prioritization. In this method, the implementation order of the requirements is determined by how much business value will be created, how time-sensitive the implementation is, how many risks are involved, and how much work is required. The method provides a formula for calculation, but the hardest part is finding at least relatively correct values for it.

The determination of the business value of ideas and requirements is left to the expertise of product management even when using SAFe®.

In order to understand customer value, sometimes an MVP (Minimum Viable Product) has to be created and sometimes an entire business case calculation has to be performed. In the best case, the customer is ready to express how much they would pay for the new requirement. In practice, however, the value will usually be pulled out of a hat and mainly overestimated.

“The hardest thing about product management is that doing the right thing for your customers means that you”™re saying “˜no”™ to them 95% of the time,” says Dave Meyer, the Senior Product Manager at Atlassian.

After the determination of value, the requirement will be moved to the Analysis column for evaluation by architects and product developers. After this step, the aim is to explore the realization of the requirement. When the workload and the other implementation costs are clear, the ratio of the expected value to the cost can be re-evaluated and it can be decided whether the requirement will be moved to the Portfolio Backlog or not.

Portfolio Kanban in Proportion to the Traditional Portfolio Funnel

The Portfolio Backlog is the highest-level backlog in SAFe® from which content is moved to the ARTs according to the teams”™ activity status. “Grooming” the backlog together with the Program Manager and business representatives is agile product development management.

Many Levels, Many Roles

Just as the name suggests, the Scaled Agile Framework (SAFe®) is scalable to large product development organizations of up to thousands of employees. In such cases, product management has to be divided between several levels. At the lowest level, the Product Owner ensures that the teams are doing the right things in the right order. The work of the teams can be combined at the Program Level, where the Product Manager is responsible for the features. Products or components can form Value Streams, which are directed at different customer segments, and the person responsible for these may be called a Solution Manager. At the highest level, a VP of Product Management, together with the persons responsible for the product areas under their management, may be discussing portfolio management with the project office and business units.

In a large organization, it is important to divide the responsibility for customer insight between different levels. In addition, activities should be prioritized at the levels with the best understanding of the work done at the level in question.

The companies that use SAFe® can have either twenty or two thousand product development employees. The more employees and the more complicated the products are, the more definition, control, and customer insight is needed. The title under which this work is done is irrelevant. SAFe® is only a framework that every company should attempt to adjust to their own needs.

SAFe® Determines Software Development, Not Product Management

When deploying SAFe®, it is worth remembering that the process has been developed to help with guiding development, not to guide work.  SAFe® best serves organizations that modify it with the aid of the Lean-Agile Principles to suit their needs.

From the point of view of product management, it is important to remember that customer value consists of many parts, of which software development is only one. SAFe® does not eliminate the need for product management, and the most important responsibilities of a product manager still are the following:

• Ensuring the customer value of requirements and ideas
• Indicating a direction for the work and ensuring that the customer”™s needs are conveyed to the right persons
• Prioritizing the work to be done

We here at Contribyte help companies to find and implement the product development methods best suited for them. We have helped and trained several organizations in the deployment of the SAFe® model and product and portfolio management. If you are interested in SAFe® or product management, please contact us.

P.S. Our SAFe® training offering is also available here.