In my prior post I promised to provide an example of how SAFe is best thought of as a model rather than as a design: a model is a tool for thinking whereas a design is something to implement precisely.
Consider SAFe’s model for portfolio management. The SAFe model defines a portfolio “kanban” process in which work is defined as a set of “business epics”. Just think of a business epic as a project: it is not really, but for our purposes you can think of it that way.
The SAFe process defines the lifecycle of a business epic, from identification of the need for the project, through alternatives analysis, through implementation. This is all pretty standard. The SAFe process is kanban-like in that it defines a single pipeline through which all business epics pass.
That works fine in many organizations, but there are many organizations that have multiple portfolios. In that case, one would need several pipelines. Some organizations tier their portfolio based on the source of funds, or by investment amount: the latter is typical in government agencies. In fact, government agencies usually have mandatory investment management processes and so one could not even use the SAFe model, but one could still use other parts of SAFe. Indeed, the SAFe guidance says that one should expect to have multiple “kanban systems”.
Such complications means that there often cannot be a single backlog. Another complicating factor is that it is often the case that one investment serves multiple strategic goals: yet SAFe presumes that there is a hierarchy of investment themes which are associated with epics, comprising a “release train”.
SAFe also differentiates between “business epics” and “architectural epics”. This is sometimes a useful thing to try to do, but it is not always so clear cut. For example, when a telecommunications company invests in a new network, is that a business epic or an architectural epic? Hmmm. When one adds servers to reduce customer wait time, is that a business epic or an architectural epic? Hmmm. But as the SAFe guidance points out, there might be different sources of funding and oversight for the business and architecture investments, and this might cause these investment categories to be separated.
These are not flaws in SAFe. As I explained, SAFe is a model - at least, that is how I look at it. So to apply SAFe, one should first understand the intent of the model, and then consider how that intent can be realized in one’s situation. In the example at hand, it might mean adjusting the portfolio process defined by SAFe.
My point is: do not view frameworks as designs or templates. View them as models. Create your own design.