Author: Jurgen Appelo

Have you ever had the problem of losing track of all the great benefits your product or service offers your customers? That's probably because you're not managing your Initiatives.

Have you ever had the problem that you neglected your blog, newsletter, community meetups, or social media accounts for too long? That's because you weren't managing your Initiatives.

Have you ever had the problem of having too many ideas and experiments, with most half-finished or barely started? That's because you need to... well, you get the point.

To stay sane in a world with ever-increasing demands and opportunities, you must start managing your Initiatives.

I will explain shortly.

But let's begin with a clarification.

Products, Small to Large

Products and services come in all sizes. There are huge products the size of entire platforms, such as Spotify and Disneyland, and there are products the size of an afternoon snack, such as a cappuccino with oat milk or the time tracking tool I use to measure my daily productivity—I use Toggl Track, it’s pretty good.

Small Product/Service

Imagine a horizontal scale indicating the size of products and services. On the left, we find teams responsible for multiple small products, often for various stakeholders. For example, the coffee shop around the corner may have a team of five part-timers working with different time schedules and jointly responsible for many products and services: fresh coffee beverages, homemade cakes, various lunch options, etc. On a global scale, there exist many such teams struggling with an array of small products and services.

Large Product/Service

At the other end of the scale, large organizations—we often call them enterprises—manage large products, usually with multiple teams responsible for different product areas. For example, an online retailer might have a dedicated Product Search team, Browsing Experience team, Shopping Cart team, and so on. Each of these teams owns a small area of a large product. Because an enterprise has dozens or even hundreds of such product area-focused teams, we're talking about a lot of teams worldwide managing separate product areas—small parts of huge products.

Medium Product/Service

In the middle, between the two extremes of large and small products, there is a middle segment where each team is responsible for precisely one product. For example, this could be the two software development teams that build a smartphone app and a website for an insurance company. The handful of engineers—plus maybe a Product Owner and a Scrum Master—are together precisely the right size to build one product. Again, at a global scale, many teams are situated in this middle segment.

Scrum and SAFe Target Audiences

The Scrum framework was created for teams in the middle: those developing one software product. That's how the Scrum Guide was written: one Product Team with one Product Backlog, one Product Owner, and one Product Goal. Easy-peasy. Teams working on medium-sized products are Scrum's target audience.

However, it's not like the whole world sits squarely in the middle. The success of Scrum meant—not surprisingly—that people wanted to use it for larger products, where teams were responsible for separate product areas. This led to the rise of SAFe (among others) with its focus on managing dependencies between the various product area teams. Agile scaling frameworks cater to large products and services. Teams working on a product area within a large product are the target audience for SAFe.

But what about the teams at the other end of the scale—those handling small products? There are no "reverse-scaling" frameworks. Scrum and SAFe were not designed with these teams in mind. Teams with small products must adapt the standard frameworks to make them workable in their context or create their own way of working. There seems to be no framework targeting the teams juggling multiple small products. Maybe we need an alternative "reverse-scaling" approach!

I'm willing to see if we can fix that problem.

An essential first step is to introduce the concept of "Initiatives."

What Are Initiatives?

At the time of writing, The unFIX Company is a "core team" of three people (plus several joint ventures led by entrepreneurial people). The Core Team handles official partnerships, community+ memberships, online meetups, in-company workshops, a public newsletter, social media accounts, and more. As a small team, how would you handle such a situation where your products, services, and customer experiences are all over the place?

You could start with an overview of Initiatives.

The people working at a coffee bar need to be aware they jointly share responsibility for the beverages, cakes, lunches, restrooms, reading table, and social media accounts. A tech startup's founders are responsible for the app, website, customer service, supplier relations, investor relations, and more. The employees working in an HR team are responsible for a recruitment funnel, training programs, compensation structures, employee development programs, labor law compliance, and much more.

An Initiative is all the work needed to offer (discover, deliver, and improve) something of value to a defined set of stakeholders. It is something the team provides to their clients.

Note: You may use the terms provisions, propositions, offerings, properties, or anything else. The exact terminology doesn't matter to me. What's important is the idea behind what I describe here.

The weekly newsletter you offer to your customers is an ongoing Initiative. The helpdesk portal you maintain to handle service requests is an Initiative. The free downloadable goodies you use to attract new customers are an Initiative. Your app's account and profile settings, where customers can manage all their personal preferences, are an Initiative. The reporting tool you use to offer clients insights into data analytics is an Initiative. The quarterly Open Innovation Day you organize with customers is an Initiative.

Each Initiative should have a Name, Description, defined Stakeholders, an Initiative Owner, a place in an Exploration or Exploitation portfolio (more on that later), and a defined Lifecycle Stage (also more on that later.) That's how we will manage them: as things with a lifecycle stage sitting in a portfolio with other Initiatives (competing for your time).

Value Streams, User Journeys, Features and Products

Some might wonder, "Aren't you just talking about value streams, user journeys, features, or products?"

No, I don't think so.

Value streams are abstract processes; they don't actually exist. An Initiative depends on one or more Value Streams, and each Value Stream supports one or more Initiatives. (For example, our blog initiative depends on my blog writing value stream, while the blog writing value stream supports the blog initiative and our LinkedIn page initiative as well.)

A User Journey is about the typical steps customers and users take. Each Initiative enables one or more User Journeys, while each User Journey is enabled by one or more Initiatives. (For example, our courseware materials and workshop software initiatives enable the partner workshop facilitation journey.)

A Feature is one individual thing that users and customers appreciate (or not). An Initiative depends on many Features, and each Feature supports one or more Initiatives. (For example, your Open Innovation Day initiative may have a feature for customers to connect with each other on LinkedIn.)

A Product is something people can (or should) pay for to get it. Each Initiative can offer several Products. (For example, an employee training program may provide various training products the company paid for.) But a Product can also include one or more Initiatives. (For example, one training product might consist of in-person workshops and self-paced learning initiatives.)

Still confused?

Don't worry. Just ask yourself, "What needs regular attention and care to keep some of our stakeholders happy?" Those are probably your Initiatives.

An Epic Disaster

The Scaled Agile Framework defines an Epic as "a significant solution development initiative." (Note the word "initiative" here!) The concept is similar to what I mean by an Initiative. However, there are several issues.

First, in SAFe, epics are always BIG. They only exist at the Portfolio level when multiple ARTs develop interrelated features for one large Initiative. However, I'm not convinced that only a high-level portfolio team manages a portfolio. Initiatives are scale-free! A small marketing team, a three-person startup, and a Facilitation Crew of coaches also need to get a handle on their portfolio of Initiatives (even though they do all the work themselves).

Second, SAFe offers no guidance for monitoring and maintaining epics after completion of the features. When teams finish their work, the epic at the portfolio level is "Done" as well, and nothing else happens to the epic within the context of SAFe. But I believe an Initiative is only "done" when it is actively retired and killed. Until then, it still exists—like that company blog you last posted on five years ago and is slowly degrading on your website.

Initiatives are different: they are managed within one team, even teams with small products, and they don't magically disappear after the delivery of features. The Initiative still exists and will require ongoing maintenance and improvement until you actively make it go away.

Interestingly, the SAFe definition of an epic differs from its original meaning in Extreme Programming and other agile methods, where an epic was just "a large user story." SAFe stole borrowed this original idea of a large story and wrecked turned it into sort-of-but-not-quite an Initiative. On the one hand, SAFe epics enter into an "idea funnel" with a pitch and multiple stages (like Initiatives—yay!). On the other hand, SAFe adds "business outcomes" and "leading indicators" to epics, meaning they are treated as Objectives. And yes, Objectives magically disappear when completed, but Initiatives don't. They keep hanging around seemingly forever, like your mother-in-law.

This makes epics in SAFe incredibly confusing as they sit halfway between Initiatives and Objectives.

What Scrum and SAFe Ignored

Popular methods and frameworks have no concept of Initiatives. Scrum and SAFe assume that everything a team works on contributes to a single product or product area. This means Scrum and SAFe are difficult to adopt by small teams handling multiple products and services as they can't have one Product Backlog with one Product Goal. Their work is just too fragmented across multiple Initiatives.

Scrum and SAFe don't manage Initiatives in Exploration and Exploitation funnels across multiple Lifecycle Stages, from a new idea in the Initiation Stage to the killing of it in the Termination Stage. Okay, SAFe does half of it by first treating epics as Initiatives (in a funnel with stages), but then it turns them into Objectives (with outcomes and metrics). I’d say to SAFe, make up your mind!

Is the concept of Initiatives only applicable to teams with small products? No, not at all! Teams developing medium or large products can also benefit from an overview of Initiatives.

For example, the team using Scrum to build a medium-sized app for an insurance company may define account sign-up, profile settings, insurance claims, document archive, and customer service as their Initiatives. They can treat their product areas or MMFs (Minimum Marketable Features) as Initiatives.

The Shopping Cart team using SAFe at a large online retailer might have credit cards, debit cards, mobile pay, tax calculations, and delivery forecasts as their defined Initiatives. Like the Scrum team, they can see their (mini-)product areas or MMFs (Minimum Marketable Features) as Initiatives.

When something starts as an idea, is nurtured and cultivated across lifecycle stages, and must be actively retired and killed to get rid of it, it is worth treating as an Initiative.

Managing Your Initiatives

Anything that you continuously or continually make available to stakeholders is an Initiative. An Initiative never spontaneously disappears. It needs frequent monitoring and regular maintenance. You should manage your Initiatives in portfolios across lifecycle stages.

I will write about that soon.

When you manage your Initiatives, you will keep track of all the great benefits your product or service offers your customers because you have a visual portfolio.

When managing your Initiatives, you won't neglect your blog, newsletter, community group, or social media accounts because you will regularly evaluate capacity across Initiatives.

When you manage your Initiatives, you won't have too many half-finished or barely-started ideas and experiments because you'll be managing Exploration and Exploitation funnels.

In future blog posts, I will describe how to manage Initiatives with a regular assessment and how this influences your goal-setting process (with Objectives) and daily work (with Activities).

Do you like this work? Join as a partner • Join the community • Sign up for updates • Hire us for a talk • Book a workshop

(Presentations and visuals are available to unFIX partners only.)

Initiatives: What Scrum and SAFe Ignored