Implementation Strategies for Business Epics
By Alex Yakyma
Note: This article is part of the Community Contributions series, which provides additional points of view and guidance based on the experiences and opinions of the extended SAFe community of experts.
Introduction
Business epics are large initiatives in SAFe that drive business value and typically cross the organizational boundaries (release trains), time boundaries (PIs), or both. It is a key capability of the agile enterprise to properly analyze and sequence business epics for implementation. While it’s easy to think of epics as big, binary, monolithic, committed blobs of work, the reality is they should be implemented incrementally to achieve the benefits of agility. Moreover, once the technology, benefits, and economics are understood, some won’t deserve to be fully implemented, as the initial effort delivers most of the potential business value.
In this article we will discuss different strategies for incremental epic implementation dependent on the epic type:
Program Epic – an initiative that is constrained to a single program.
Portfolio Epic – involves more than one program.
We assume that the reader is familiar with Epics, Business Epic, Architectural Epic and Epic Kanban System, and since we will be referring to some principles of Product Development Flow, the Lean-Agile Mindset article in SAFe also provides some important background.
Incremental Decentralized Implementation
Epics are defined as a single whole, but each epic undergoes incremental implementation. Moreover, in the case of a portfolio epic, programs have certain flexibility and authority in implementing their own pieces. However, the way this works is not as simple as splitting an epic into a set of program epics and fully authorizing the programs to implement their portions the way they want. The implementation needs to be aligned across all participants to be able to introduce meaningful milestones to the process and adjust the implementation based on the feedback.
In SAFe, epics go through the Kanban system where the necessary research and analysis activities are conducted, and a go/no-go decision is eventually made. During analysis, a lean business case is being developed for each epic, which among other aspects contains a description of the implementation strategy for the epic. This strategy is a bridge from the centralized decision regarding the epic into its decentralized implementation by programs.
Program Epics
Program epics are the simplest case because there are no material dependencies with other programs, but even here mistakes can be made. Following are the possible strategies for implementing a program epic:
Spike first. Before starting the implementation, the program runs spikes in the previous PI to learn more about the epic prior to the next PI planning, as Figure 1 shows. The spikes may target different aspects of the epic: whether or not we should implement it at all, how to implement it, what technology to use, what’s best for the end user in terms of the functionality, etc. These research activities typically occur at the Analysis stage in the Business Epic Kanban, are reflected in the lean business case and impact a go/no-go decision for the epic.
Please note that even though epics may span multiple PIs, here, and in every example below, we assume that in every PI there is working software that implements a portion of the epic.
Some features first. In this case, we implement part of the epic that fits into the PI and then revise again at the next PI boundary, based on whether we want to proceed with the epic, or stop because the epic success criteria have been largely achieved or the initial features show insufficient customer interest. Figure 2 shows this scenario. Unlike in the case with spikes, delivering features provides more value and deeper and more meaningful feedback, but it comes with the price – it takes more effort. In certain cases, it can be wise to commit to only a few initial features that would generate feedback sufficient to make a meaningful go/no-go decision for the rest of the effort.
Both of the scenarios above reflect the realization of an important Lean principle – Understand and Exploit Variability. Supported by fast feedback loops, we can make better economic decisions as soon as we learn from delivering only the current increment.
In these scenarios, we also assume that sufficient Architectural Runway already exists for the Business Epic. In many cases however, we need to build a specific architectural enablement that would extend the existing runway to better support the business epic. This typically means that there is an Architectural Epic associated with the Business Epic. We’ll highlight three such strategies below.
Architectural epic first. In the case when there is an architectural epic associated with the business epic, it may be good to implement that entire epic first, as shown in Figure 3.
In many cases, implementation can be done more efficiently as the following patterns describe.
Architectural effort precedes business functionality by one PI. This allows reacting faster and changing decisions earlier before the architectural enablement is fully built as Figure 4 illustrates.
Architectural effort precedes business functionality by one or a few iterations. In this case, as Figure 5 shows, teams have a lot more flexibility but it also requires careful adjustments at the iteration level.
Now that we have discussed the implementation strategies for program epics, it is easier to describe the portfolio epic case, as we have known scenarios to refer to. Also, the reader has probably noticed that the ability to split an epic into a set of thin vertical slices is an extremely important skill for the enterprise. SAFe’s Business Epic and Architectural Epic articles contain specific guidance on how to split such epics.
Portfolio Epics
In the case of the portfolio epics, the story is complicated by the fact that there are multiple trains involved. Let’s look into some useful strategies.
Split into program epics and fully decentralize control. Figure 7 illustrates this scenario. In this case, the decisions made by the trains will be faster and more efficient. However, this case is only possible when less coordination is required between the trains and they work in different codebases that realize different physical systems. But even in this case, a high-level coordination may be required to streamline the implementation and eliminate waste.
In this scenario each program can utilize the practices described above for program epics.
Take a vertical slice of an epic across all trains and revise after a PI. This way it requires more high-level coordination but introduces an important milestone that may help the organization to adjust the further effort or even cancel the epic in favor of some other initiatives that drive better economic value (see Figure 7).
Overall this approach is quite similar to “some features first” at the program level, only that in this case the entire organization iterates. In some cases, the scenario below is more effective.
One program implements some features, others wait. In the case when there’s a lot of uncertainty associated with an epic, some implementation or business risks involved, it may be wise to follow the pattern described in Figure 8.
The “Spike first” approach that we outlined before is also applicable and strongly recommended for portfolio epics. Structurally it is very similar to the pattern described in Figure 8, although the research effort occurs in the analysis stage.
Concurrent/sequential implementation with an architectural epic. This case is quite similar to its analogue for program epics, however, it can get complicated based on which trains are involved in what. Even though in many cases it is better when each train concurrently implements their portions of both, in some practical applications this isn’t possible. An example could be a “platform” train that delivers some generic, framework-level functionality to the other trains. Sometimes this train implements the entire architectural epic or most of it, while other trains will concurrently deliver their part of the business epic or on the opposite – will wait until the platform train finishes their work.
Summary
In this article, we considered multiple scenarios for balancing business epics in the SAFe enterprise. An incremental approach and centralized/decentralized decision making drives optimum economics. The incremental approach utilizes fast feedback and drives re-evaluation at certain points in time, and is the key to maximizing business value. But even though the principles apply in all cases, there is no universal rule to the implementation, so patterns described in this article require careful consideration depending on the context.
