6 SAFe® practices that make sense also for S sized teams

Feb 14, 2017 / by Juha-Markus Aalto

SAFe – Scaled Agile Framework® – was created to tackle the challenges of M – XXL sized projects. Such projects consist of several agile teams having in total from ~50-100 up to hundreds or even thousands of practitioners. How about S sized projects with just one or a few teams, is there anything in SAFe for them or is Scrum just enough? If the team is a relatively independent pure software team and the project is short, Scrum (or Kanban) would be the way to go. However, an S sized team can benefit from selected SAFe practices at least under the following circumstances:

  1. Strategic software product with a long lifespan. The longer the lifespan of the SW product, the more important it is to link SW development explicitly to the strategy of the enterprise. Scrum doesn’t provide much support for linking SW development to the longer-than-sprint time span of strategic goals.
  2. Expectation to scale up from S to M size. If a startup (a new business or an internal startup) has a strong projection for growth, it makes sense to prepare for it up front and use approaches that scale up when needed. Scaling up can be terribly slow and challenging unless the scaling capabilities have been built from the ground up.
  3. Dependencies with multiple (non-SW development) teams. It’s not rare that a company has a relatively small SW team delivering SW for multiple other teams for integration. The SW teams in hardware and services companies with moderate SW assets but a decent portfolio of products face this situation. Software companies whose product is heavily tailored for each customer through delivery projects have this multi-project challenge, too. All the dependent teams need to agree on priorities and plan together.
  4. Necessity to invest in long term capabilities such as DevOps. Focusing on delivering the next set of user stories, sprint by sprint, easily sets aside longer term investments in team’s own capabilities. It’s easy to agree that DevOps capabilities are needed but becoming a true DevOps team requires efforts that need to be planned and executed like a project. Changing the development technologies or modernizing the software architecture are other examples of long term capability investments that are true projects on their own right.

There are ways to handle all these four cases with pure Scrum but my own experience suggests that it’s better to cherry-pick the following 6 practices of SAFe to deal with them.

S sized team Safe practicesReproduced with annotations added by Juha-Markus with permission from © 2011-2017 Scaled Agile, Inc.  All rights reserved. Original Big Picture graphic found at scaledagileframework.com. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile Inc

1. Strategic Themes

All companies, big or small, need a strategy to be successful. It is crucial to understand how the products of the company create value to customers in terms of impact to processes/doing and the concrete benefits customers gain.  Product quality and the user experience are equally important for the long term success. In addition to product strategy, a software development team needs to have an idea how to continuously improve its SW engineering capabilities to improve its productivity and competitiveness.

While SAFe does not offer explicit tools to identify the value creation logic nor for building the strategy, it does have Strategic Themes that are the business objectives that connect team’s portfolio to the strategy of the enterprise.

I have used Strategic Themes as explicit planning domains in iteration planning (Program Increment Planning as well as in Sprint Planning) to ensure that the team works on strategically relevant items. Some tools such as Visual Studio Team Services (VSTS, the one my current team uses) allow tagging the work items with theme keywords which further helps analyzing the backlog items vs. strategy. If a strategy exists, the step to identify the strategic themes requires only little effort so I think it’s worth it.

2. Program Epics

Scrum teams typically interpret epics just as too big user stories that don’t fit in one sprint. SAFe contains a rich hierarchy of epics to ensure sufficient scaling: Portfolio (business) Epics and Enabler Epics, Value Stream Epics, and Program Epics. Portfolio and Value Stream Epics are not relevant for small scale development but Program Epics are.

SAFe defines Program Epics as “initiatives significant enough to require analysis using a lightweight business case and financial approval before implementation”. I assume that the requirement to prepare a business case for something is not the very point here; the point is to ensure that an Epic is something that creates desired significant value and is doable. Thus, when a team works on a (Program) Epic linked to a Strategic Theme, team’s effort contributes to something valuable that is aligned with the strategy of the company.

Epics are useful for an S sized team as they describe the key initiatives of a team that are ongoing or being proposed by its stakeholders or invented by the team itself.  A SW team should have also some Enabler Epics in its portfolio in addition to Business Epics to e.g. improve its architecture or DevOps capabilities.

As “significant enough initiatives” tend to require significant investments (relative to resources), so a light weight business case is worth doing for each Epic before jumping to implementation or rejection. This is particularly useful when the team has several stakeholders and their initiatives need to be prioritized and matched to team’s resources in order to make the prioritization discussion meaningful.

3. Program Kanban

SAFe contains scalable Kanban systems to manage portfolios of initiatives at enterprise, value stream and program levels. The program level is sufficient for an S sized team and it is particularly useful in the case that the team has several stakeholders offering their own Epic proposals for implementation.

Program Kanban of SAFe provides a simple and transparent process to deal with the proposals for initiatives. It is used for capturing, analyzing, approving and tracking Epics. Epics that end up being done go through the Funnel, Review, Analysis, Portfolio Backlog, Implementation and finally Done states. For an S sized team the process to study the Epics can be extremely lightweight but these logical steps should be present anyway when the Product Owner thinks of the next initiative(s) and how the team can create most value. Managing the key initiatives as Epics on Program Kanban requires only moderate effort but gives good transparency to team’ priorities at portfolio level – also to the members of the team.

4. Features

Feature is not really a part of the core definition of Scrum. There are just user stories. The big user stories are labeled as epics and a related bunch of user stories as themes.

SAFe defines Feature as “a service provided by the system that addresses one or more user needs”. Features elaborate Epics and the Features are defined in terms of their benefits and acceptance criteria. Features are exactly what they sound like – the mainly functional characteristics of the product that ‘all’ are interested in. I have found it difficult to explain team’s plan and progress in terms of user stories to customers, dependent projects or to the management but Features as defined in SAFe work great for that purpose. They are of suitable size and understandable whereas Stories tend to become too small and numerous.

What makes the Features particularly useful is that they are sized to fit in one Program Increment. That makes Features concrete deliverables and facilitates clear communication with stakeholders.

5. PI Planning

Scrum contains just the sprint cycle of typically 1-3 weeks (2 weeks being probably the most popular) as the planning and execution iteration. More often than not, Scrum teams provide true visibility to their plan for just the next sprint plus the backlog that hints at the order in which the user stories become possibly implemented. Different variations of PowerPoint and Excel roadmaps are used to address the need for longer-than-the-next-sprint visibility. Backlog tools typically allow planning the stories for future sprints and some provide forecasts based on team’s velocity and the ranks of backlog items.

Program increment (PI) in SAFe is “a cadence-based interval of building and validating a full system increment, demonstrating value and getting fast feedback”.  The duration of one Program Increment is typically 8 – 12 weeks so 4 – 6 sprints (in SAFe terms ‘iterations’) of 2 weeks. The last sprint of the Program Increment is Planning and Innovation Iteration which will be discussed as the sixth practice below.

Just like there is Sprint Planning in Scrum, SAFe provides a planning practice for these super-sized iterations: PI Planning. I have conducted PI Planning workshops of SAFe more or less by the book also for S sized projects. The planning horizon of 8 – 12 weeks is short enough for accurate planning and long enough for the team to achieve something really valuable, a set of potentially shippable Features. I think PI Planning workshop is good use of time for all: the team gets an update of the ‘bigger picture’ and priorities and prepares the planning in an agile way. The stakeholders can contribute to the planning directly and get an overview of all work items that the team is engaged with. For an S sized team, the PI Planning workshop can be condensed into one (long) day so the investment of time is reasonable with regards to the benefits.

6. Innovation and Planning Iteration

Thomas Edison described his innovation approach as “one per cent inspiration and ninety-nine per cent perspiration”, so innovations require time and hard work, not just creative mind. Especially in ‘never ending’, continuous product development there is 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 is probably even harder to find time to work on some more risky, seemingly lower priority yet innovative ideas.

SAFe doesn’t have any silver-bullet solution to magically release lots of time for developers to innovate like Edison but its Innovation and Planning Iteration at the end of each Program Increment is something that teams should appreciate. This sprint should not have any new stories to be developed yet e.g. some system integration and testing activities, such as performance or security testing, may be done. Also the achievements of the Program Increment will be demonstrated to stakeholders and PI Planning for the next Program Increment conducted. But as the name suggests, during this sprint the team can also have a hackathon or otherwise work on innovations or e.g. infrastructure improvements. And last but definitely not least: the team can have a break from the hectic SW deliveries. Part of the break can be used for e.g. competence development.

Those were my half a dozen SAFe practices that I have found useful also for S sized teams. Strategic Themes shortlist the strategic priorities and help the team align with those. (Program) Epics define the value of key initiatives that the team needs to work on so that those can be meaningfully prioritized.  (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 they are sized so that each of them fits in one Program Increment of 8-12 weeks. PI Planning happens at Program Increment cadence building a shared understanding of priorities and goals for the next 8-12 weeks. Innovation and Planning iteration at the end of each Program Increment gives the team a well-deserved break and allows the team to spend some time on innovating and developing its capabilities.

Juha-Markus Aalto leads product development of digital services at Qentinel. He has made an instrumental contribution to the lean and scalable requirements model of SAFe and implemented an XXL sized agile-lean transformation program when he worked at Nokia Corporation.

Topics: DevOps, Lean, Agile

Juha-Markus Aalto

Written by Juha-Markus Aalto