In the end, a vision without the ability to execute is probably a hallucination.

— Steve Case, AOL co-founder

Startup SAFe at FirstRoot

By Luke Hohmann, Founder and CEO of FirstRoot, Inc. and SAFe Framework Principal Contributor

For companies looking to embrace agility and balance transformation while delivering customer value, SAFe’s principles, competencies, and practices form the foundation of a new way of operating.

We know that SAFe works in enterprises with dozens to hundreds of teams, which naturally leads many to think of it as applicable only to large organizations. Unfortunately, this limits the benefits that enterprises receive from SAFe because SAFe’s practices also apply to small organizations and individual initiatives within larger organizations.

This article describes how we are using SAFe at FirstRoot, Inc, a SaaS startup. The lessons we’ve learned apply to organizations of any size, particularly startups who want to scale and larger organizations who seek to accelerate innovation in Horizon 3 of their Lean Portfolio Management (LPM) process.

Background

FirstRoot is a technology startup that provides the world’s first software platform and integrated curriculum to support Participatory Budgeting (PB) in schools [1, 2]. As a tech startup, FirstRoot must either create or select a product development process.

Historically, the only choice was to create the process, as early agile methods were insufficient to meet the needs of a startup. Scrum and XP, for example, lack guidance on essential decisions for creating a successful startup, including:

• Establishing a company/product strategy
• Developing an economic model
• Creating a roadmap linking strategy to execution

Entrepreneurs and intrapreneurs had to invest valuable time and energy modifying these development methods with additional practices required for success.

In contrast, SAFe provides a complete solution, enabling entrepreneurs to start small, focus on execution, and scale with confidence. SAFe promotes customer centricity, design thinking, cadence-based development, release on demand, and team practices vital to a startup. SAFe also offers the tools necessary to make investment decisions that help companies balance near-term needs with strategic investments. Finally, SAFe delivers a common set of processes and practices that enable globally-distributed development teams to work more effectively, scaling quickly to support the startup’s growth.

Starting with Portfolio SAFe

Small organizations start with the Portfolio configuration of SAFe as it provides the guidance necessary to:

• Establish a startup with agile values and a growth mindset
• Support startups in making high-impact investment decisions that align strategy and execution
• Guide startups in creating strong relationships with suppliers
• Ensure that startups are building the right thing, the right way
• Provide startups with a means to measure progress
• Help startups establish a strong core team that can adapt to change and growth

The remainder of this article will describe how FirstRoot uses Portfolio SAFe to accomplish all of these goals.

Establishing a Startup

This section shows how FirstRoot used SAFe to form the business and provide a strong foundation for growth. In launching a startup, we must clearly define its purpose, the business model to realize it, measurement metrics, and the principles to guide us on our journey.

Establishing the company purpose

Every CEO must establish the purpose of their company. Every Product Manager must establish the purpose of their product. Both can be accomplished using the Golden Circle, a technique developed by Simon Sinek to clarify the essential purpose of a company or product (Figure 1).

As a startup, FirstRoot applies the Golden Circle to the entire company:

• Why: FirstRoot’s purpose is to promote greater economic equality and civic engagement
• How: Participatory Budgeting in schools
• What: FirstRoot sells schools a software platform and integrated curriculum that teaches financial literacy and civics through Participatory Budgeting. In support of our public benefit charter, we make our platform freely available to families.

Establishing the business model

The Business Model Canvas (BMC) is a one-page template that summarizes the most important aspects of a business model. SAFe advocates that larger enterprises use the BMC to clarify their existing business strategy or concisely define new opportunities. Startups like FirstRoot use the Business Model Canvas for similar reasons: to help determine business strategy and define opportunity. We use the excellent Strategyzer tool suite to manage the development of our canvas as we refine our business model based on market feedback (see Figure 2).

Establishing Key Performance Indicators (KPIs)

Every enterprise must track the performance of its solutions. SAFe Enterprises use Lean Portfolio Management (LPM) to establish and track the KPIs for each solution, each portfolio, and the entire company (see the SAFe KPIs article for more information). Startups must also monitor company performance, and we found the SAFe KPI article helpful in establishing our company and solution KPIs. In alignment with our Benefit Corporation status, we include financial and social impact KPIs as both output and outcome metrics. You can read more about FirstRoot’s KPIs here.

Developing the Operational Value Stream

Operational value streams (OVS) denote the sequence of activities needed to deliver a product or service to a customer. Unfortunately, startups often resort to heroic efforts to implement a product or service. They may work initially, but they don’t scale.

As a startup begins to develop its first OVS, SAFe’s emphasis on customer-centricity and design thinking is invaluable. It helps the fledgling enterprise move from heroics to repeatable, scalable value streams. SAFe’s recommendation to align personas, customer journey maps, and OVSs is invaluable to maintain alignment among every functional group within FirstRoot, improving marketing, sales, and onboarding. You can read more about FirstRoot’s personas, journey maps, and other design artifacts here.

Instilling a Lean-Agile Mindset through SAFe Values and Principles

SAFe defines a set of values and principles applicable to every enterprise, regardless of company size or maturity. It also describes a Lean-Agile mindset that leaders should embrace to establish a resilient, adaptable, and fun culture. Together, these form a strong foundation for growth. At FirstRoot, we’ve done our best to enthusiastically adopt SAFe values, principles, and the Lean-Agile mindset. We have emphasized instilling a growth mindset, enabling FirstRoot to overcome some substantial challenges, described later in this article.

Making High-Impact Investment Decisions

Every company needs a process for making decisions that align investments with strategy. SAFe manages this through the Lean Portfolio Management (LPM) competency.

The LPM competency supports a range of enterprises. In a startup, we have one portfolio with only one solution. This means that we’ll immediately use and keep many of the SAFe LPM constructs while also tailoring and/or deferring some aspects of SAFe LPM until needed to support scale. The mix of these choices will vary based on the startup. Here are the choices we have made in building FirstRoot, as illustrated in Figure 3.

Aspects of LPM to Keep

There are many aspects of SAFe LPM that are directly applicable to startups. We have found the following especially valuable.

Strategic Themes

• Strategic themes are the differentiating business objectives that align the portfolio to the business strategy. These themes guide product and development activities and are associated with metrics that enable the startup to measure progress. As of Q2/2021, FirstRoot had established strategic themes in two foundational areas: product and company (see Table 1). Product foundations support solution creation and business hypotheses validation
• Company foundations focus on sufficient capital and prepare for growth:

Epics and the SAFe Lean Startup Cycle

Because launching a startup represents a significant investment for the founders and angel/seed investors, the founding team needs a mechanism for deciding how to spend their seed funding. SAFe Epics are the containers for Solution development initiatives that capture substantial investments.

Epics ensure that the startup is making the highest possible impact investments. They enable the founding team to have a structured discussion over which investments will best advance the startup and how much seed capital to risk.

Particularly common in startups, Enablers are the investments needed to create the Architectural Runway required for future business functionality. The choice of our client development platform was a particularly critical enabler for FirstRoot. Our development team narrowed down the possibilities to React and Flutter.

To make the best decision, we applied the SAFe Lean Startup Cycle (Figure 4). We defined a functionality set and evaluated React with a minimum viable product (MVP) application. When the evaluation failed, we decided to pivot, evaluated our available options, and created the same MVP using Flutter. After we assessed the results, Flutter passed our tests. It was clear that Flutter was the best choice for our needs.

Not every team member had experienced this kind of process. Indeed, some were ready to make React work, which suggested they were succumbing to the sunk cost fallacy. We used this opportunity to reinforce a growth mindset, helping all team members support the change.

Aspects of LPM to Tailor

Here are some of the aspects of LPM that we have tailored to meet our needs.

Developing the Vision

A Vision is a description of the future state of the solution under development. Because most startups have just one solution, the product vision is usually the same as the company’s solution. And when a startup has only one product, the portfolio vision construct can be tailored to simply be the product vision. At FirstRoot, our product vision is a ‘beautiful, easy-to-use solution for Participatory Budgeting (PB) in schools’. To guide our development and ensure ease of use, we’ve established some core usability KPIs. For example, we aim to create a solution in which a new user can create an account and establish a PB cycle for a school in less than five minutes.

Maintaining focus through the cadence

In SAFe, the effective operation of the LPM function relies on three significant events:

• A quarterly Strategic Portfolio Review
• A monthly Portfolio Sync
• A bi-annual Participatory Budgeting meeting to manage investment decisions

At FirstRoot, we keep the cadence of the Strategic Portfolio Review and modify the participants to be the leaders in the company and our external advisory board. We keep the monthly Portfolio Sync cadence, but since we only have one solution, this meeting becomes a monthly review of our product’s progress (including a KPI review). We leverage Participatory Budgeting when making critical choices in investments, which have mostly concerned our relationships with external service providers.

Portfolio and Product Roadmapping

A large enterprise will have one solution roadmap for each solution and one roadmap for the entire portfolio. Startups like FirstRoot can collapse this into a single solution roadmap. We have invested quite a bit in capturing our understanding of market rhythms, as the timing of education markets is well-known and can be leveraged for growth.

Aspects of LPM to Defer

There are several aspects of SAFe’s LPM that larger enterprises require that a startup can defer:

• You don’t need the portfolio canvas and solutions by investment horizon because there is only one solution
• You don’t need a Lean-Agile Center of Excellence (LACE) or Agile Program Management Office (APMO)
• You don’t need to worry about value stream coordination because you only have one value stream

A healthy, growing startup will naturally add these elements as necessary.

Creating Strong Supplier Relationships

Most startups rely on external suppliers for marketing, sales, and development. Since a common cause of startup failure is ineffective supplier management, maintaining positive supplier relationships is essential.

We have found SAFe Managed-Investment Contracts invaluable in helping us create relationships with suppliers that have helped us thrive. Here are some additional practices that we employ to establish these relationships:

• When possible, use a partner you know and trust. If you can’t find a partner from your direct experience, ask for help from investors, advisors, and your network.
• Give them a fair commitment. For our development partner, we use 6-month contracts. For our marketing partner, we use 3-month contracts with variable funding for additional marketing needs.
• Keep all suppliers on the same cadence.
• When the partnership is new, shorter duration iterations create more opportunities for interaction and feedback. Our development teams started with and continue to use one-week iterations.
• Educate, educate, educate. A new development supplier may not know SAFe’s Lean-Agile principles and practices. If possible, have them attend Leading SAFe training along with watching SAFe Agile Software Engineering video series to align everyone on development practices. Make sure your suppliers understand your mission, vision, and purpose. We regularly review our investor ‘pitch deck’ with all suppliers to maintain alignment.

Build the Right Thing

Arguably, the most significant risk to any startup is building the wrong thing. Fortunately, SAFe’s Agile Product Delivery competency provides several practices that enable a startup to maximize its chances of creating the right product.

Understanding the Customer Needs

The first step in SAFe’s product delivery approach is the Continuous Exploration of the customer and market needs through market research and hypothesis-driven development. FirstRoot has engaged in both secondary market research to develop financial models of the market size and value and primary market research to identify critical stakeholder needs. We also conducted hypothesis-driven development through Minimum Marketable Features (MMFs).

Developing a Compelling User Experience and Visually Appealing User Interface

Having a clearly defined purpose is not enough: A company must also create a differentiated solution. FirstRoot’s primary differentiation is visually appealing, easy-to-use software. SAFe supports this goal through personas, customer journey maps, and story maps. You can view our tailored personas and customer journey maps here.

Before the Story Map, there must be a Story

Our story maps deviate from regular SAFe practice. Before there was a story map, there was a story describing a persona solving a problem with our solution. At FirstRoot, we shared these stories as graphic novels. This format enabled our product and design team to communicate the essential goals of our customers and stakeholders better than a conventional story map or collection of user stories.

Introducing and Refining Features through Feedback Friday and Future Friday

One aspect of SAFe we find especially helpful is backlog refinement. We have created two cadence-based backlog refinement events, which we alternate every week: Feedback Friday and Future Friday.

Feedback Friday is a one-hour meeting focused on customer feedback, reviewing data from experiments and telemetry data from our application. Feedback Friday helps the team understand the true source of Epics, Features, and Stories — the students, teachers, parents, and administrators using FirstRoot. It also helps the team understand how feedback and requests transform the artifacts we need to create our offerings, including personas, graphic stories, journey maps, and prototypes.

Future Fridays is a one-hour meeting that introduces the Agile Team to any upcoming Feature or Enabler work, giving them a forum in which to ask questions and provide quick feedback.

Validating the Vision while Building Iteratively

While developing new solutions, Agile teams face inherent tension. They must validate key business hypotheses even as they incrementally create the product. We resolve this by designing and usability testing our full product vision, including all the PB cycle phases. We then scale back and create more refined designs for each iteration.

As expected, we have found that sometimes the refinement process changes aspects of the designs and workflows we validated with users. We absorb small changes as part of the normal refinement process. Substantial changes motivate additional usability testing to confirm that the change is advancing the solution.

Figure 7 shows a vision with portions of the full user workflow perspective. Each iteration builds some subset of the user workflow. We intentionally chose a more depth-first approach so we could validate with actual users after each iteration. For example, the first goal was to validate the interface for proposal submission and portions of the workflow that will be built across several iterations.

Building the Right Way

Building the right solution isn’t enough for sustained success: you need to build it the right way. Here, the technical foundations and decision-making processes of SAFe are vital.

Understanding what ‘good’ Agile development looks like

Because Agile teams work differently than traditional teams, a new agile team needs to understand what ‘good’ development looks like. An ideal starting place is helping new agile teams understand SAFe’s Built-In Quality and Continuous Integration – Continuous Deployment (CI/CD) practices. We accomplished this by adding Stories to our backlog that asked each member of the Agile Team to watch the SAFe Overview and SAFe Agile Software Engineering video. We scheduled one video per week and then discussed how we would leverage these videos in our development work. We’re not perfect, and we’re still evolving our development practices. The SAFe ASE videos helped us start our development with a shared model of what good looks like.

Establishing a development cadence

The SAFe practice of decoupling the development cadence from the release process is critical. Development teams need predictable schedules to manage their personal and professional lives, but market needs should determine release timing.

FirstRoot is a distributed team, with members in India, Mexico, and across the United States. We quickly settled in on a one-week iteration cycle and selected meeting times that minimized time zone challenges. A shorter iteration helped us forge relationships. In addition, it forced us to create smaller deliverables and maximized our opportunities for sharing our insights during routine iteration meetings.

Although we developed working software in a few weeks, we didn’t have enough value to warrant a full release to the market for several iterations. However, once we released our software, we found opportunities to improve our CI/CD pipeline. We’re now comfortable with a variable release process, in which we sometimes release updates multiple times in a day. At other times, we hold off for a few iterations to incorporate significant improvements.

Planning a Program Increment when you have nothing

In the standard, larger practice of SAFe, an Agile Release Train (ART) (typically 50 to 125 people) delivers value in the form of working software throughout a planned Program Increment (PI) which is normally 8-12 weeks. But the planning increment is not mandated by SAFe, and startups (and often Horizon 3 solutions) have significant differences that warrant consideration on the PI length.  Shorter PIs provide faster feedback, and in our case this is facilitated and necessitated by:

• We don’t have an ART; we have one or two teams
• We have no in-flight solution; we’re creating a solution from scratch
• We have much more uncertainty, so we need faster cycles for learning and adjusting

Addressing the ART size is easy: Creating a “tiny ART” of one to three agile teams works just fine. In SAFe, the Agile Team is an essential organizational construct. If you get the teams right, it is easy to combine them into ARTs.

The more complicated challenge is how to get started when you have nothing. Startups require time to address questions, such as who their users are and what technology to build on. We scaled the Agile concept of Sprint ‘0’ to a PI ‘0’ and used the SAFe implementation roadmap to focus on the activities shown in Figure 9. The goal was to build enough working software and architectural runway to enable an effective PI Planning cadence. Once we’ve accomplished that, we moved into the more typical quarterly PI cadence.

Choosing your SaaS Solution Context

SaaS startups often start development activities by selecting a cloud hosting provider without fully realizing that this choice has significant ramifications. In SAFe terminology, the cloud hosting provider defines the solution’s context — the critical operating and infrastructure capabilities that heavily influence future business opportunities. Fortunately, the major SaaS cloud hosting providers offer a wide variety of capabilities that make development, deployment, and operations fast and efficient.

Because several FirstRoot team members were familiar with it, we initially chose Heroku for our SaaS solution context. Knowing this form of bias can be dangerous, we tested our decision by creating a small number of architectural spikes to confirm that Heroku would meet our needs. As we have grown, we continue to evaluate our SaaS Solution Context to ensure it will continue to meet our needs.

When you have no solution, it is all architectural runway

Architectural runway refers to the investments made in technical infrastructure that make future development faster, easier, and less costly. When we first launched FirstRoot, most of our initial work was building infrastructure and validating technology decisions. Choosing what architectural runway to create is critical: Startup leaders must trust their experience without succumbing to what Fred Brooks referred to as the ‘Second System Effect,’ the tendency to over-engineer or add unnecessary features to new systems based on inflated expectations, imagined requirements, and overconfidence [8].

Here are some of the choices we made in the FirstRoot architectural runway and the business reasons that motivated them:

• I18N/L10N: Our architectural runway included Internationalization (I18N) of our solution to support multiple languages (Localization, or L10N), enabling FirstRoot to support users whose primary language is not English.
• A cross-platform client: Students, teachers, and parents will be accessing FirstRoot on a wide range of devices. Our solution needs to support a substantial number of them: Modern browsers running on PCs and Macs, Chromebooks, and tablets, along with iOS and Android smartphones.
• A gorgeous UI: The vast majority of educational technology solutions are ugly and hard to use. We wanted to deliver the same level of visual appeal that students find in video games.
• An API-driven model: Modern solutions use APIs for interoperability and scalability. API-driven design also helps clarify contracts and enables Test-Driven Development.

Compliance and Standards

SAFe provides substantial advice on how development practices enable a company to build solutions that comply with applicable regulations [see Achieving Regulatory and Industry-Standards Compliance with SAFe]. However, each enterprise must identify which are relevant and determine how the solution will comply.

Because FirstRoot is a mix of EdTech and FinTech, we have several regulations that govern our software; FERPA, CCPA, and COPPA in the United States, GDPR in Europe. Our mission helps identify other standards that guide our activities, such as the W3C Accessibility Standards to support people with disabilities.[3]

We seek to fully comply with all regulations to bolster trust in our brand, and we have integrated several of SAFe’s compliance recommendations into our development activities. For example, we review our data model and event processing architecture to ensure compliance with applicable data privacy regulations. And we consider our designs in the context of accessibility.

Leveraging Patterns

The patterns movement transformed software development, enabling developers to create higher quality solutions faster. We think of patterns as part of our architectural runway. The right patterns allow us to build and evolve the architecture, infrastructure, and solution easier, faster, and more economically.

FirstRoot has leveraged two kinds of patterns – architectural and data model. The main architectural patterns we leverage are event-sourcing [4] and CQRS [5]. Every action in our system is a discrete event, which enables us to scale, create audit trails, and easily support multi-user, collaborative operations. By separating commands from queries, we can further partition our system to support huge numbers of users. Because patterns don’t solve specific domain problems, we use custom-state models to manage Participatory Phases and the states of proposals within these phases.

We also extensively leverage David Hay and Martin Fowler’s data model patterns [6] [7]. Our solution’s most vital data model pattern is the Party pattern, used to manage entities, roles, relationships, and rights. We have implemented a Knowledge Level for metadata, structures, and information about the system, and an Operational Level to manage the data within the system.

Making significant technical investment decisions

As discussed earlier, every company must have the means to make appropriate investment decisions, which is supported by SAFe’s Lean Business Case. The Lean Business Case is a short document that captures critical information to assist leaders in making a high-impact decision.

To illustrate, we are now facing a significant technical decision of whether to stay with our current cloud hosting provider or change to a new one. As this article is going to press, we are developing a Lean Business Case to help inform our decision. This effort is not a wasteful activity in “Big Up-Front Design” (BUFD) or succumbing to overbuilding our solution (YAGNI). Instead, the Lean Business Case is an invaluable tool helping us:

• Identify the most important attributes of the decision
• Explore alternatives
• Develop the Minimum Viable Product (MVP) that will provide critical data for the decision
• Consider the ramifications of this decision on existing customers
• Determine if this initiative is more valuable than others

Summary

While not every startup will choose SAFe, I am hopeful that this article has shared a fresh perspective on how startups that seek to scale in the future can use a method designed for the goal. My hope is that by starting with SAFe, you’ll find it easy to scale and success will more naturally find its way to you.

Appendix: How the FirstRoot BHAG motivates SAFe

One way to determine if your startup would benefit from SAFe is to clarify your goals. For example, if we were creating a bespoke solution for a single school, or if we were less concerned with compliance and security, SAFe might be overkill. As it turns out, our ambitions are much greater.

The term BHAG (Big Hairy Audacious Goal) was created by Jim Collins to define an inspiring goal that focuses a company for years of work. The FirstRoot BHAG is $1K – 1M – $1B: We want to put $1K into 1M schools globally and watch what happens when students can control $1B in capital to make their schools — and our world — a better place.

The FirstRoot BHAG immediately conveys significant requirements on our solution:

• FirstRoot has to be global because there are only 130,000 K-12 schools in the United States.
• FirstRoot needs to invest in significant software development and develop the infrastructure of a secure, standards-compliant, modern, global SaaS company.
• FirstRoot has to be inclusive because we want all students to participate. Practically, FirstRoot must embrace a whole host of Non-Functional Requirements (NFRs), ranging from accessibility and Internationalization (I18N) to significant logging.
• Because we’re dealing with children, FirstRoot must be fully compliant with applicable laws and regulations, ranging from FERPA and COPPA in the U.S. to GDPR in the EU. And we are certain new laws will emerge over time.

The solution FirstRoot is creating, the market we’re serving, and the scale in which we are operating motivated our adoption of SAFe:

• Our goals require the ability to scale: While scale, in and of itself, is not a worthwhile goal, FirstRoot’s objective of reaching more than one million schools globally will require an organization of considerable size. By starting with SAFe, we can immediately adopt a proven set of practices that enable us to rapidly and reliably scale FirstRoot.
• SAFe has more of what we need than any other method: SAFe is a curated blend of many best practices, integrated into a cohesive set of choices. SAFe explicitly leverages wisdom and tools from many books focused on entrepreneurship: Beyond Entrepreneurship, Business Model Generation, Value Proposition Design, Lean UX, and Principles of Product Development Flow have all influenced SAFe.
• SAFe practices can be adjusted in a sensible manner: The consistency present in SAFe provides entrepreneurs with the ability to make practical adjustments that drive their organization forward. For example, a startup ART can be one to three teams in size!
• SAFe is broadly accessible: While small, FirstRoot is distributed, with team members in multiple locations in India, Mexico, and the United States. SAFe’s global infrastructure means that all members of the organization can benefit from a common set of training and skills development.

References

[1] 72 Frequently Asked Questions about PB: https://unhabitat.org/sites/default/files/download-manager-files/72%20Frequently%20Asked%20Questions%20about%20Participatory%20Budgeting%20%28English%29.pdf

[2] Participatory Budgeting in Schools: https://youtu.be/vr–MR3L8Lk

[3] W3C Accessibility Standards. https://www.w3.org/WAI/standards-guidelines/

[4] Event Sources. Martin Fowler. https://martinfowler.com/eaaDev/EventSourcing.html

[5] Event Sourcing and Command-Query Segregation Principle (CQRS). https://www.eventstore.com/blog/event-sourcing-and-cqrs

[6] Hay, David. Enterprise Model Patterns: Describing the World. Technics Publications, LLC, 2011.

[7] Fowler, Martin. Analysis Patterns: Reusable Object Models. Addison-Wesley Professional, 1996.

[8] Brooks, Frederick P. The Mythical Man-Month. Addison-Wesley, 1975

Last update: May 26 2021