This article is for someone considering SAFe® for their small to mid-scale adoption. Many organizations are adopting SAFe because it provides a method for multiple teams to work better together. SAFe is attractive because it provides more structure than “Scrum-of-Scrums” and provides guidance on business strategy, budgeting, management, shared services and DevOps. But it can also be overly complicated, particularly for small to medium sized organizations.
This article discusses:
- what defines being small to mid-scale
- the challenges many organizations need to overcome
- how Essential SAFe provides needed structure and practices to organizations with multiple teams
- how Essential SAFe may work well at large-scale but is not designed for smaller scales
- a simpler, more effective method of Lean-Agile Product Management that can improve Essential SAFe adoptions
- more effective workshops than SAFe’s for small to mid-scale
- adopting SAFe at small to mid-Scale
Note: for a more in-depth article on this topic see Adopting SAFe at small to mid-scale in depth.
What defines being small to mid-scale
We define small-scale as when no more than a small team of product owners drives all of the teams in the organization. This means that they can meet amongst themselves and decide what’s important, from an entire corporate view, what needs to be done and resolve any conflicts that sub-teams (e.g., ops) may have in the technology group. While small-scale is defined by these dynamics and not actually by size, small-scale organizations are usually between 30-150 people in technology.
We think of mid-scale as organizations that require multiple product managers to provide guidance to even more product owners to bridge the gap between the business stakeholders and technology. In this case a small team of product managers is responsible for deciding what is important for the entire organization. They then work with a few teams of product owners who direct the teams. Again, while mid-scale is defined by these dynamics and not by size, mid-scale organizations can be up to 1000 people in technology.
The challenges many organizations need to overcome
Many small to mid-scale organizations face the challenge that their development teams are not as effective as they would like them to be. Releases take too long and miss the mark of what’s needed, there is poor product quality, misunderstood requirements, and even small changes take a long time to get done. The causes for this are surprisingly common and include working on too many things, unclear requirements, teams not working well together and inconsistent methods.
How Essential SAFe® provides needed structure and practices to organizations with multiple teams
There are two general Agile approaches taken when multiple teams are involved – organic and structured.
“Organic” means to have teams come together on their own to solve problems broader than any one team by itself could. This is the Scrum of Scrums approach and can work well when there is already a high degree of collaboration and understanding of Lean principles present.
Essential SAFe takes the other approach – have management create an eco-system within which teams can work together towards the goals of the business stakeholders of the organization.
Its 10 Essential Elements of SAFe provide the core of Essential SAFe.
- Lean-Agile Principles
- Real Agile Teams and Trains
- Cadence and Synchronization
- Program Increment (PI) Planning
- DevOps and Releasability
- System Demo
- Inspect and Adapt
- Innovation and Planning (IP) Iteration
- Architectural Runway
- Lean-Agile Leadership
If the reader is not familiar with these it is suggested they do a quick read of 10 Essential Elements of SAFe before proceeding.
Essential SAFe provides many of the core concepts, practices and roles needed for teams adopting Agile. However, these were designed for programs in a large organization which creates challenges of its own, as we shall see.
How Essential SAFe® may work well at large-scale but is not designed for smaller scales
Essential SAFe is too heavy for small to mid-size organizations
Essential SAFe was designed for programs working in large organizations. In such situations, what goes on the product backlog is provided to the program. At smaller scales, there is an opportunity to use a lighter weight Agile product management method that works more effectively than the Full SAFe approach while being much less complex. The dynamics at smaller scales also creates the opportunities for shorter program increments. These should be no more than 4 weeks at small-scale and 8 weeks at mid-scale. While planning events, common cadence and synchronization are essential, the size of the batches of work can be much smaller. In addition, an innovation and planning sprint is much longer than it needs to be. Innovation should be present on a mostly continuous basis at small to mid-scale while planning requires less preparation at these scales.
Essential SAFe does not include driving from business
While Essential SAFe provides much needed guidance, its intention to be used by programs that are in large organizations has it not include how to drive organizations from strategy through value realization. While this is included in the larger levels of SAFe, it is just as important to smaller organizations. If small to mid-scale organizations attempt to use the concepts of the levels above Essential SAFe they will get more than they need.
A simpler, more effective method of Lean-Agile Product Management that can improve Essential SAFe adoptions
SAFe uses a cacophony of terms – epics, features, enablers, MVP, MMF, capabilities, solutions, solution trains, value streams and more in its Agile product management system. These terms are sometimes overloaded and even re-defined from their original use. While that may be necessary at Full SAFe, it is certainly not necessary at smaller scales. It is worth investigating some of these terms to understand how a simpler model is available.
A minimum viable product (MVP) is a product with just enough features to satisfy a market segment of customers and to provide both value and feedback for future development work. Gathering insights from an MVP is often less expensive than developing a product with more features, which increases costs and risk if the product fails, for example, due to incorrect assumptions. The term was coined and defined by Frank Robinson about 2001 and later popularized by Eric Ries with his Lean Startup in 2011 where the market segment in question are early adopters.
SAFe has adopted Ries’ definition. But building new products or software that supports new services to early adopters is quite different from creating extensions to existing software with known customer market segments. Robinson’s original meaning of MVP was later described as the Minimum Marketable Feature (MMF) by Denne and Cleland-Huang. The challenge with both terms is that it presumes the software is the focus – which is not true for many IT organizations. SAFe uses MMF as part of its Lean-UX approach even though the book Lean-UX on which it is based, does not mention MMFs. The bottom line is that SAFe’s MVPs, MMFs, capabilities, value streams and solution trains creates a cacophony of overloaded and redefined terms.
While MVPs are a great term for building new products or software supporting new services to a new market of early adoptions, it is:
- Geared toward startups
- Designed for the first time a product/service is released to early adopters
- Usually built by a small team that can already pivot
The question is, what do you do when:
- You are an established company?
- You are building enhancements to an existing product/service?
- The teams required to build it are not aligned and don’t work together well?
In the situations where the value of an enhancement or new product/service is reasonably known, we want to deliver small increments of value based on the strategies of the organization. While usually focused on the customer, we can think of these as business increments – since they are being created for the overall benefit of the organization. We want this value to be delivered as quickly as possible. To do this, we can define a sequence of small business increments each of which is delivered as quickly as possible. We call these Minimum Business Increments (MBI). MBIs are not a reason to deliver less, but are intended to help us deliver value sooner.
MBIs are a critical step in bridging business stakeholder’s objectives as shown in figure 1.
MBIs are created by first determining who your target audience is. This target audience may be external or internal. Then, decide on the scenarios for this market for the business objective in question. Focus on the minimum business increment for the scenarios in question – and that becomes your MBIs. Very often you will commit to a series of MBIs as the desired functional implementation you want to do for an epic. By building and delivering them incrementally you get both value and feedback quicker – providing you an opportunity to pivot. Note that this business value should be based on what represents value for the business and its customers. MBIs must, of course, contain all of what’s needed to realize value. This means that any marketing, architectural work, support work, side-affects of one group on another, …, must be included in the MBI. This provides for greater alignment when multiple teams are involved.
By using a combination of MBIs and MVPs when applicable, the connection between strategy and ops can be strengthened. MVPs will usually be created by one team. MBIs will likely require multiple teams. By sequencing the MBIs with Weighted Shortest Job First (WSJF) everyone in the organization can see what is most important and resolve conflicting requests using this sequence as guidance. This provides alignment.
More effective workshops than SAFe’s for small to mid-scale
Virtually all of SAFe’s training is designed around the needs of large organizations. This means Leading SAFe® and Implementing SAFe® have a significant amount of content that is not designed for smaller organizations. It also means that opportunities for delivering workshops targeted to smaller organizations is lost. By focusing on the needs of smaller organizations than SAFe’s target market, workshops can be provided that train groups of teams along with their product managers/owners. By using advanced training techniques these workshops can be done for up to 90 people while, perhaps surprisingly, being of a higher quality. The reason is because they can take advantage of large group team building exercises that teach lean-principles
In addition, by focusing on just what parts of SAFe is needed, initial workshops can include an essential practice for Agile product management – Acceptance Test-Driven Development. While it is not required to go as far as automated testing, teaching the advantages of a test-first mindset up front is incredibly valuable, provides immediate improvement to development teams and thereby reduces any resistance they may have to the new adoption.
Adopting SAFe at small to mid-scale
The approach to adopting SAFe at small to mid-scale should take advantage of what Essential SAFe provides while recognizing new opportunities are available with the smaller scale. This can be accomplished by:
- Leadership and management taking a short workshop to learn the basics of SAFe at small-scale.
- Product Managers/Owners learning Agile Product Management.
- Release Train Engineers(RTEs) getting up to speed in the approach espoused
- Teams learn Essential SAFe as applicable
- Teams adopt Scrum or Kanban if they do not already know Scrum or Kanban integrated with the discovery and specification phases of Acceptance Test-Driven Development
This can be done in a surprisingly short period of time by focusing on just what’s needed from SAFe and adding what else is useful. Note that the workshops being referred to are not affiliated, nor endorsed by SAI (the providers of SAFe) nor do they offer SAI certification.
Absorb what is useful, reject what is useless, add what is specifically your own. – Bruce Lee
Using Essential SAFe for small to mid-scale at first appears attractive. However, as you realize what’s not in it that’s needed and how much of it is for the context of a program in a large organization, not a “program” that represents the entire company, it becomes clear it’s not always a good choice.
Building off of proven patterns of success and challenge enable your organization to use existing methods that are tailored to your needs. By using a “framework” that provides guidance on how to make decisions you can move more quickly than trying to follow a framework that was designed for everyone.
For frameworks to be effective they should help you understand the problems you’re facing and the solutions available to you. While one can think of epics in the right way, it’s much better to have the concept built into the framework. This gets everyone on the same page.
The approach espoused in this article has been being used by Net Objectives even before SAFe existed. If you are interested in learning more please contact Mike Shalloway to set up a free consultation.
Lean-Agile Product Management
Article on the Minimum Business Increment.
Article on Create Clarity on What Represents Value for the Business and Its Customers
Lean-Agile Product Management white paper.
Acceptance Test-Driven Development
Acceptance Test-Driven Development using Behavioral-Driven Development
Benefits of Acceptance Test-Driven Development using Behavior-Driven Development.
Cross-functional teams: Improving communication between people who work together.
Aligning Multiple Teams with Lean-Agile Thinking.
Product Manager and Product Owner (Case Study).
Running Effective Planning Events.
Read Dependency Management, Collaboration and Planning at Small-scale which describes different ways of running planning events
Watch a recording of Al Shalloway’s Agile 2018 presentation Lean Leadership and Systems Thinking.