By Juha-Markus Aalto, Director Product Development, Qentinel Group
SAFe has been designed to tackle the challenges of ‘M to XXL’ (medium to extra, extra large-sized) programs. Such programs consist of several Agile teams with approximately 50–100 people, or even as many as hundreds or thousands of practitioners.
But what about ‘S-sized’ (small) development organizations with just one or a few teams? Is there anything in SAFe for them—or are Scrum and Kanban just enough? The answer, of course, is it depends. Read on to find out what those things are.
If a pure software team mainly works on short programs, Scrum or Kanban would seem to be the way to go. However, while a full-scale use of SAFe practices, roles, and events wouldn’t make sense for an S-sized project, a small team can certainly benefit from selected SAFe practices, at least in one of the following situations:
Strategic software product with a long lifespan – The longer the lifespan of the software product, the more important it is to link software development explicitly to the strategy of the enterprise. Scrum provides little support for linking such development to the longer-than-sprint time span of strategic goals.
Dependencies with multiple non-software development teams – It’s common for a company that has a relatively small software team to develop solutions for other teams for integration. For example, software teams face this situation in a hardware or services company that has a decent portfolio of products but has just a moderate amount of software assets. Software companies whose products are heavily tailored for each customer, through delivery, have this multi-project challenge, too; all the dependent teams need to sync and agree on priorities and plans.
Necessity to invest in long-term capabilities such as DevOps – Intense focus on delivering the next set of user stories, sprint by sprint, may result in great products, but it’s all too easy to forget about investments in the team’s own capabilities. We can all probably agree that investing in DevOps capabilities is worthwhile to achieve higher quality and faster time-to-market. However, becoming a true DevOps team doesn’t happen overnight. It requires planning and executing, as you would do for any project. Changing the development technologies or modernizing the software architecture are other examples of long-term capability investments that are, in fact, true projects.
Expectation to scale from S to M size – If a startup (a new business or internal business unit) expects strong growth in the near future, it makes sense to prepare for it up-front and use Agile approaches that scale when needed. Unless the foundational capabilities have been built from the ground up, however, scaling can be painfully slow, difficult, and challenging.
There are several ways to handle these four cases with pure Scrum or Kanban, but experience suggests that it’s better to apply the following six practices of SAFe to deal with them more effectively (Figure 1):
Strategic themes shortlist the portfolio’s strategic priorities and help the team align with them.
Program epics define the valuable key initiatives that the team needs to focus on so that the team can meaningfully prioritize their backlog.
The program Kanban shows the priorities and status of epics for the stakeholders.
Features elaborate epics, thereby providing a common language for the team and its stakeholders. Features are sized so that each fits in a single PI.
PI planning happens on a cadence, building a shared understanding of priorities and goals for the next 8–12 weeks (depending on the chosen cadence).
The innovation and planning iteration held at the end of each PI gives the team a well-deserved break from the urgent and allows it to spend some time on innovating and developing its capabilities.
Figure 1. Scaled Agile Framework with six practices for S-sized teams
Companies big and small need a strategy to be successful. It’s crucial to understand how a company’s products create value—how they affect processes and the concrete benefits that customers gain. Product quality and user experience are equally important for long-term success. In addition to product strategy, a software development team needs to have an idea of how to continuously improve its engineering capabilities so as to increase its productivity and competitiveness.
While SAFe does not offer explicit tools to identify and build the strategy, it does have Strategic Themes. These themes are the business objectives that connect the team’s portfolio to the strategy of the enterprise.
I’ve successfully used strategic themes during sprint (Iteration) planning to help ensure that the team works on strategically relevant items. Some tools, such as Visual Studio Team Services (VSTS), allow the tagging of work items with theme keywords, which further helps match backlog items with strategy. If a strategy exists, the extra step to identify the strategic themes requires minimal effort.
Scrum teams typically interpret epics just as really big user stories that don’t fit in one sprint. SAFe defines epics as “initiatives significant enough to require analysis, using a lightweight business case and financial approval before implementation.” The requirement to prepare a business case is not the point here. Rather, the important point is the need to ensure that an epic creates significant value and is feasible.
SAFe contains a rich hierarchy of epics to ensure sufficient scaling: Portfolio Epics, Large Solution Epics, and Program Epics. Portfolio and large solution epics are not relevant for small-scale development, but program epics are. Moreover, when a team works on a program epic linked to a strategic theme, the team’s efforts contribute to something valuable and are aligned with the company’s strategy.
Epics are useful for an S-sized team. They describe the ongoing key initiatives, those proposed by stakeholders for such an initiative, or those invented by the team itself. Software teams should also have some enabler epics in their backlog, in addition to business epics, to improve architecture or DevOps capabilities.
As ‘significant-enough’ initiatives tend to require significant investments of people, development of a lightweight business case is recommended for each epic before determining its approval for implementation or rejection. This process is particularly useful when the team has several stakeholders, and each initiative’s priority and capacity need to be understood to make trade-off discussions meaningful.
SAFe uses Kanban systems to manage initiatives at the portfolio, value stream, and program levels. The program level is sufficient for an S-sized team, and it’s particularly useful if the team has several stakeholders offering their own epic proposals for implementation.
SAFe Program Kanban provides a simple and transparent process for capturing, analyzing, approving, and tracking epics. Completed epics will have passed through six states during this process: funnel, review, analysis, backlog, implementing, and done. For an S-sized team, the process to study epics can be extremely lightweight. Even so, these logical steps should definitely be present, so the Product Owner will know that the team can create the most value for the next time. Managing the key initiatives as epics in the program Kanban requires only moderate effort but offers transparency into the team’s priorities at the program and portfolio levels.
A Feature is not really a part of the core definition of Scrum; there are just product backlog items. Many Scrum teams borrow ‘user stories’ from Extreme Programming (XP), however; they label big stories as ‘epics’ and bunch related stories together as themes.
SAFe defines a feature as “a service provided by the system that addresses one or more user needs.” Features elaborate epics and are defined by their benefits and acceptance criteria. Features are exactly what they sound like—the main functional characteristics of the proposed product. It can be difficult to explain the team’s plan and progress to customers, members of dependent projects, or management through user stories alone. In contrast, features, as defined in SAFe, serve that purpose well. Their size is suitable and understandable, whereas user stories tend to become too small and numerous.
What makes features particularly useful is that they’re sized to fit in one Program Increment (PI). As a result, they are concrete deliverables, facilitating clear communication with stakeholders.
Traditional Scrum teams work in a sprint cycle, which is where the planning and execution of work occur, with two weeks being the most popular duration for a sprint. More often than not, Scrum teams provide true visibility into their plan for just the next sprint, along with the backlog, which hints at the order in which the user stories might be implemented. Different variations of PowerPoint and Excel roadmaps are typically used to address the need for longer-than-the-next-sprint visibility. Backlog tools can help plan stories for future sprints, and some provide forecasts based on the team’s velocity and the order of the backlog items.
In contrast, a program increment in SAFe is “a cadence-based interval for building and validating a full system increment, demonstrating value, and getting fast feedback.” The duration of a PI is typically 8–12 weeks, or four to six sprints of 2 weeks. The last sprint of the PI is the Innovation and Planning (IP) Iteration, which is discussed in the next section.
Just as there is sprint planning in Scrum, so SAFe provides a planning practice for these super-sized iterations, known as PI Planning. In my own experience, I have facilitated SAFe PI planning, more or less by the book, for S-sized teams. The planning horizon of 8–12 weeks is short enough for useful planning and long enough for a team to achieve something really valuable: a set of potentially releasable features.
The PI planning event is a good use of time for all participants. The team gets an update of the bigger picture from the business, which includes the vision and priorities and develops an Agile plan. The stakeholders can contribute to planning directly. They also get an overview of all the work that the teams will do during the PI. For an S-sized team, the PI planning event can be condensed into one long day so that the investment of time is commensurate with the benefits.
Thomas Edison described his innovation approach as “1 percent inspiration and 99 percent perspiration.” In other words, innovations require time and hard work, not just a creative mind. In ‘never-ending’ continuous product development, there’s a risk that a team just executes sprint after sprint without taking a break and becomes exhausted. Sprints tend to be hectic, and for an S-sized team, it’s likely to be harder to find time to work on some more risky, seemingly lower-priority, yet innovative ideas.
SAFe doesn’t have any silver-bullet solutions to magically free up lots of time for developers to innovate like Edison. Even so, its IP iteration, which occurs at the end of each PI, is something that teams should appreciate. No stories are planned for this iteration. Instead, teams have an opportunity to do some final system integration and testing activities, such as performance or security testing. The program-level retrospective, known as the Inspect and Adapt (I&A) event, is also held during the IP iteration. During the I&A workshop, the achievements of the PI are demoed to stakeholders, with this demo followed by a retrospective and problem-solving workshop. The IP iteration is also where we plan our next PI.
More importantly, as the name suggests, the IP iteration is the time for innovation. During this iteration, some teams do a hackathon or work on innovations or improvements in infrastructure, refactor code, or improve architecture. Last but definitely not least, the team gets a break from the hectic pace of software deliveries. Part of the break can be used for competence development, as an example.
Scrum and Kanban by themselves can be just enough for S-sized teams. However, in at least four circumstances, using select SAFe practices, along with Scrum or Kanban, is clearly more effective:
Strategic software product with a long lifespan
Dependencies with multiple non-software development teams
Necessity to invest in long-term capabilities like DevOps
Expectation to scale from S to M size
There are ways to handle these four cases with pure Scrum or Kanban, but experience suggests that it’s better to apply the six practices of SAFe described here to deal with them more effectively.