Six SAFe Practices for S-Sized Teams
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 up to hundreds or thousands of practitioners.
Are Scrum and Kanban Enough?
But what about ‘S (small)-sized’ 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. Please 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 under one of the following situations:
- A 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 which has a decent portfolio of products but has just a moderate amount of software assets. Software companies whose product is 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.
- The necessity to invest in long-term capabilities like 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 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) has a strong projection for growth, it makes sense to prepare for it up-front and use Agile approaches that scale when needed. But, unless the foundational capabilities have been built from the ground up, scaling can be painfully slow, difficult, and challenging.
Applying Six SAFe Practices for S-Sized Teams
There are 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.
Strategic Themes
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 to increase productivity and competitiveness.
While SAFe does not offer explicit tools to identify and build the strategy, it does have Strategic Themes—these 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 analyze backlog items against the strategy. If a strategy exists, the extra step to identify the strategic themes requires minimal effort.
Program Epics
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, it’s to ensure that an epic is something that 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 strategy of the company.
Epics are useful for an S-sized team. They describe the ongoing key initiatives, those proposed by its stakeholders, 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, 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 needs to be understood to make trade-off discussions meaningful.
Program Kanban
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 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 the following states: funnel, review, analysis, backlog, implementing, and finally, done. For an S-sized team, the process to study epics can be extremely lightweight. But these logical steps should be present anyway, so the Product Owner will know that the team can create the most value for the next time. Managing the key initiatives, like epics, in the program Kanban requires only moderate effort but offers transparency to the team’s priorities at the program and portfolio levels.
Features
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) and 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, dependent projects, or to management through user stories alone. But features, as defined in SAFe, serve that purpose well. Their size is suitable and understandable, versus user stories, which tend to become too small and numerous.
What makes features particularly useful is that they’re sized to fit in one Program Increment (PI). That makes them concrete deliverables, facilitating clear communication with stakeholders.
PI Planning
Traditional Scrum teams work in a sprint cycle, which is where the planning and execution of work occurs, with two weeks being the most popular duration. 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.
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 two weeks. The last sprint of the PI is the Innovation and Planning (IP) Iteration, which will be discussed in the next section.
Just as there is sprint planning in Scrum, SAFe provides a planning practice for these super-sized iterations, known as PI Planning. 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 directly to planning. They will 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.
Innovation and Planning Iteration
Thomas Edison described his innovative approach as “one 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 release lots of time for developers to innovate like Edison. But its IP iteration, at the end of each PI, is something that teams should appreciate. No stories are planned for this sprint. However, it’s an opportunity to do some final system integration and testing activities, such as performance or security testing. It’s also where the program level retrospective, known as the Inspect and Adapt (I&A) is held. During the I&A, the achievements of the PI will be demoed to stakeholders, followed by a retrospective and problem-solving workshop. The IP iteration is also where we plan our next PI. But as the name suggests, the IP iteration is the time for innovation. This is where some teams do a hackathon or work on innovations or improvements in infrastructure, refactor code, or improve the architecture. And last but not least, the team can have a break from the hectic pace of software deliveries. Part of the break can be used for competence development, as an example.
Conclusion
Scrum and Kanban by themselves can be just enough for S-sized teams. However, there are at least four circumstances that I’ve found that using select SAFe practices, along with Scrum or Kanban, is 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 following six practices of SAFe to deal with them more effectively:
- 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 they can meaningfully prioritize their backlog.
- The program Kanban shows the priorities and status of epics for the stakeholders.
- Features elaborate epics, thus providing a common language for the team and its stakeholders. And 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.
About the Author
Juha-Markus Aalto leads product development of digital services at Qentinel. He’s made several contributions to the Lean and scalable requirements model of SAFe and has implemented an XXL-sized Lean-Agile transformation program when he worked at Nokia Corporation.
Last update: 2 October 2018
