Uncategorized Archives

SAFe and Business Architecture – Lean and Agile Journey with SAFe

Posted on June 14, 2021

As organizations begin their Lean and Agile journey with SAFe®, SPCs will introduce a tool designed to help organizations determine the best, most logical place to launch their first Agile Release Train (ART). The Value Stream and ART Identification Workshop are designed to help organizations identify the sweet spot where an opportunity to deliver value intersects with a clear problem to solve, leadership support, a clear product or solution, and collaborating teams.

It’s challenging to meet the criteria mentioned above, which is why many are tempted to launch ARTs within easier-to-identify constructs such as organizational silos. This rarely works. As we know, value often does not follow the organizational hierarchy. However, it’s important to understand that value stream identification is the first step in an ongoing practice of flow management to optimize the speed of delivery, quality, and customer delight.

Why we perform value stream identification

Words matter, and there’s a clear distinction between value stream identification and value stream mapping. We advocate identifying value streams as you get started with SAFe. Value stream mapping is an ongoing practice of understanding, tuning, and planning how the organization will deliver value against its strategy in the long term.

Value stream identification is something we seek to accomplish in a day or two
Value stream mapping is a practice that we sustain indefinitely

Depending on an organization’s state of maturity in the realm of business architecture, one can inform the other, and neither is independent of the other.

The role of business architecture

The role of business architecture is to provide clarity of how an organization’s capabilities and infrastructure come together to deliver business outcomes. The business architect is responsible for developing artifacts that help the organization operationalize strategy and assure the operational and technological enablement of core capabilities across value streams. In the context of this post, it’s important to understand the difference between how business architecture and SAFe use the word “capability.”

Capability, as defined by SAFe: Artifacts that may originate in the local context of the solution or occur as a result of splitting portfolio Epics that may cut across more than one value stream. Another potential source of capabilities is the Solution Context, where some aspect of the environment may require new solution functionality. In a SAFe context, the delivery of a capability requires collaboration between more than one ART.

Capability, as defined in business architecture: An expression of what a business does and can do.

Though when exploring the discipline of capability modeling, the nuance between the two definitions disappears, the terms in common usage may cause confusion early on. It’s likely that we’ll dive deeper into the relationship between SAFe and business architecture and provide more clarity of how the two disciples come together on a midterm horizon. To provide additional understanding of how these words may come together, consider the context of a shipping services provider.

Capability: Package tracking.

Process: Generate tracking number.

Value stream: From order received to package delivered.

System: System ‘X’ is the system used to realize the tracking capability.

Service-oriented architecture (SOA) or microservice: Tracking could be an SOA service or microservice depending on the architecture of the system. But either instance refers to the specific mechanisms that deliver the intent of the capability.

Capability (as used in SAFe): Real-time package tracking.

Notice how capability, as defined in SAFe, extends the functionality of how capability is defined in the context of the business architecture discipline. This may give an indication of how future guidance could evolve.

Value stream mapping

The goal of value stream mapping, as defined in business architecture communities, is to map value delivery processes from concept to cash within a business. The SAFe definition of an operational value stream, the sequence of activities needed to deliver a product or service to a customer, aligns with most other common definitions of the term. SAFe also provides distinction and guidance for interacting with different types of operational value streams to include fulfillment, manufacturing, software production, and supporting value streams. Depending on the altitude of your perspective within an organization, these categories of value delivery may seem too granular, too broad, or just right.

In the discipline of business architecture, architects are responsible for mapping an organization’s value streams from macro to micro. For example, a top-level value stream map for a shipping services provider may look something like this.

This simplistic view likely represents thousands of integrated software systems, multiple complex distribution hubs, scores of human hands, and millions of packages each day. Through the discipline of value stream mapping, business architects have the responsibility to understand and map how an organization does business. It starts with the macro perspective illustrated above. And continues to the micro level of how, within the context of the routing box above, shipping crates are planned, packaged, and sequentially loaded into trucks or aircraft given the specific weights, classes of service, and destinations of parcels on any given day.

SAFe seeks to optimize the operational and development value streams that make the top-level run. In the example above, there are likely operational value streams within the distribution centers that physically move packages, others that control the movement of vehicles, and still others that produce the technology to seamlessly coordinate those events, which is typically where we operate in SAFe.

SAFe focuses primarily on the development and management of development value streams, with the intent of optimizing the design/validate/deploy activities that make an operation run. Though as the world becomes more digitally integrated, the conversation is likely to evolve.

Many organizations seeking to embrace the methods outlined in SAFe lack an existing value stream body of knowledge. And one of the first steps to take to achieve a successful transformation is to begin focusing on value. The Value Stream and ART Identification Workshop helps provide the value perspective, and will likely surface organizational challenges that have historically served as a barrier to a value focus. These include communication barriers, duplicative technology systems, and business processes, and a lack of alignment within the organization. These challenges are not because of SAFe, but because the organization seeks to optimize for speed of delivery, solution quality, and customer satisfaction. You must address the problems that surfaced in value stream identification to achieve the desired outcomes.

Once an ART is launched, the work of optimizing for value delivery continues. Launching an ART will lead the organization with a powerful step forward. But to truly optimize the entire system, you’ll likely need to invest in value stream mapping through and by embracing business architecture practices.

Capability mapping

With the value stream identified, an evolution to business architecture seeks to understand the capabilities of an organization. Simply put, knowing how each of the processes on the value stream map incrementally supports the delivery of value. Capabilities provide the organization with an as-is view of how the organization operates.

For example, the ultimate goal of someone who ships a package is for that package to arrive at its intended destination on time. The capability of tracking intends to provide the customer with the assurance that their goal, the aim of the value stream, will be fulfilled as expected. Additionally, it provides transparency should the service expectations fall short.

Capability modeling

Capability modeling is an extension of capability mapping that helps inform how the business may need to alter its capabilities to achieve some sort of strategic intent. That could include improved customer satisfaction, more transparency, or even the expansion or contraction of the organization.

For organizations that want to compete in the digital age, the ability to leverage business architecture and capability modeling when testing an Epic’s hypothesis is the ultimate fuel to feed ARTs. Effective Lean Portfolio Management helps provide the objective clarity to understand the impacts of strategy and validate hypotheses. That vision clarifies how business architecture and capability mapping investments work along your journey to business agility and thriving in the digital age.

Where to start

Some level of business architecture capability exists in many organizations at some level. The best place to check if your organization has existing value stream or capability maps is with the office of the chief strategy officer.

If your organization doesn’t have existing artifacts, the SAFe Value Stream and ART Identification Workshop is a great tool to continue the conversation beyond informing the launch of the first ART. You can use the guidance in the toolkit to identify the operational value stream and apply it to your altitude of influence to fully articulate how the business area delivers value. You can reinforce your map by fully identifying the people who work within the value stream, the systems that support the value stream, and the people who work on those systems—all as guided by the workshop. The main differentiator between this effort and the initial Value Stream and ART Identification Workshop is the intent of mapping with more precision for the purpose of developing a deeper artifact, versus the initial conversation which is focused on finding the best place to launch an ART.

After you’ve articulated the value stream, you can reinforce it by considering guidance in the SAFe^® DevOps course, which helps provide visibility into lead time, process time, and cycle time. Then, with the value stream articulated and the flow metrics in hand, the organization will be able to make informed decisions on how to best improve the rate of flow within the value stream. From there, opportunities will likely emerge to expand the work into other areas of the business, explore capability mapping, expand to experience architecture, and more.

If there’s one thing I’ve learned from my years of working with Lean, Agile, and SAFe tools, it’s that well-intended, value-add work to better the organization and customer experience always yields new opportunities.

Good luck!

About Adam Mattis

Adam Mattis is a SAFe Program Consultant Trainer (SPCT) at Scaled Agile with many years of experience overseeing SAFe implementations across a wide range of industries. He’s also an experienced transformation architect, engaging speaker, energetic trainer, and a regular contributor to the broader Lean-Agile and educational communities. Learn more about Adam at adammattis.com.

View all posts by Adam Mattis

Back to: All Blog Posts

Explore more Blog Posts

Next: The Challenge of Economic Prioritization

Read the Blog Post

The Challenge of Economic Prioritization – Agility Planning

Posted on June 14, 2021

On the surface, the foundations of job sequencing in considering the Weighted Shortest Job First (WSJF) prioritization schema seem logical. Do the smallest job with the greatest cost of delay first to deliver the greatest economic benefit. Though, in practice, it can be much more challenging. To survive and thrive in the post-digital economy, organizations need to change how they produce products, interact with customers, and define and prioritize work. To succeed in each of these areas requires a significant shift in organizational behavior, including how leaders interact with their peers.

But, how did we get here?

Why does what seems right feel so hard?

What can we do?

Siloed behavior and organizational politics

Organizational structure and a slow operating cadence have created a specific environment within workplaces. One where large organizations encourage people and leaders to prioritize the work system over customer needs and speed to market.

It’s not their fault; it’s the system they inherited.

In the decades following the Second World War, the capacity to serve consumer needs had been owned almost entirely by large organizations with the capital to establish complicated supply chains and manufacturing processes. These organizations, not the consumer, dictated products, delivery cadences, and market rhythms. Until recently, those behaviors proved profitable.

2001 proved to be a proverbial “canary in the coal mine,” which indicated business disruption on the horizon. With the mass adoption of the internet, software distribution was no longer reserved only for organizations with the capital and infrastructure to produce thousands of diskettes and manuals. The dot-com era brought forth an environment that allowed any developer with access to the internet the ability to distribute software without the overhead of production. If they intended to compete, large software companies realized that they needed to be more customer-centric, faster, and value-focused. Thus, the drafting of The Agile Manifesto.

In 2021, accelerated by COVID, nearly all businesses across every sector are facing the same awakening that software companies did in 2001—no industry is safe from disruption. This time around, we’ve witnessed minimal to zero barriers to entry, a global workforce that has thrived working from anywhere, supply chains that are more nimble than ever, and desktop manufacturing capabilities that are largely inexpensive.

If storied businesses aim to survive in the threat of total disruption, they must change organizational behaviors related to strategy, workflow, and systemic behavior. Though, to change these behaviors, it’s important to understand why organizations behave the way they do.

Win culture

Win culture is pervasive within the organizational system and is the greatest challenge to overcome. The culture of winning has been hardwired into many of us from a young age, was fueled throughout the educational experience, and is carried forward into our careers.

Starting in elementary school, students are tested and ranked based on their perceived abilities. These tests determine who is placed in gifted programs, remedial programs, or in a more traditional track. Parents desperate to see their children succeed and outperform their peers push them into after-school STEM programs, language studies, and other activities. Once on the advanced track, students compete to be among the best of their group. Only the best of the best will be admitted to the best colleges. Only the best from the best colleges will be accepted into the best graduate schools and offered the most prestigious jobs.

From there, the need to win is amplified in the workplace. As one climbs the corporate ladder, the opportunity for advancement shrinks and the need to win over one’s peers becomes more frantic. Winning sometimes surpasses the team, the customer, and even the organization. It becomes about beating the competition to achieve more power, prestige, and income.

Sound familiar? This is the system we have built. To paraphrase W. Edwards Deming, a system left unmanaged becomes inherently selfish, and only management can change the system. It begins with you and how you make decisions related to defining and prioritizing work.

Take an economic view

The first principle to embrace in defining and prioritizing work, as supported by the Scaled Agile Framework® (SAFe®), is to take an economic view.

In any organization, for-profit, nonprofit, and everything in between, economics must be the primary determinant of job sequencing. Or, which jobs can I do in the shortest amount of time that will generate the most revenue, save the most on expenses, or reduce our exposure to the greatest amount of risk?

Some may argue that the statement above may not seem very customer centric, but I would argue. Consider the perspective of a nonprofit, where the ultimate goal is to serve the most beneficiaries as possible while being a good steward of donor dollars. To be successful in this regard requires taking an economic view. Consider the perspective of a for-profit, and a quote from Sam Walton, founder of WalMart. “There is only one boss. The customer. And he can fire everybody in the company from the chairman on down simply by spending his money somewhere else.” If an organization is building products that don’t represent the greatest benefit to the customer when the customer desires the benefits, the customer won’t buy the products or services. To understand which products/services/features the market demands, we must take an economic view.

Apply systems thinking

With an economic perspective in mind, the next principle supported by SAFe is to apply systems thinking. Or, accept the very real possibility that the most important job for an organization to pursue may not be the job that you personally feel is most important. One of the biggest problems with organizations that embrace a hierarchy without the benefit of a secondary operating system is that it’s easy to become myopic. People become enamored with the success of their silo and often forget that their organization alone doesn’t deliver customer value.

Systems thinking encourages us to consider the whole value stream and customer journey. The principle also reminds us that the quality of a system (or customer experience) is only as good as its slowest/most painful component. As implied by Lean, to establish flow of any sort, we achieve the greatest benefit when we seek to optimize the slowest/weakest/most painful parts of the system. By applying systems thinking as part of an economic prioritization framework, we are reminded that the work we do is part of a system. The greatest benefit to that system may be investments in areas outside of one’s own area of direct influence.

WSJF

It’s hard to make decisions about the most appropriate prioritization of work. The difficulty is amplified when arriving at that prioritization requires consensus among peer groups that are typically in fierce competition with one another.

In my consulting career, I’ve seen many scenarios. Some where the people required to collaborate for prioritization struggled to even speak to one another. Some where people were reluctant to acknowledge that the task of another was more important than their own. As consultants and change agents who may be facilitating these prioritization discussions, we must lead with empathy. Project culture in organizations was often predicated with a “do this, or else” delivery requirement. At best, missed project delivery would kill a career. At worst, it could result in immediate termination. Many leaders and executives are in a position where their long-term bonuses are still tied to this sort of incentive, or have a hangover from management paradigms of the past. Overcoming these very real fears will require leading by example and providing psychological safety. Consider collaborating with an organization’s change partners to develop a strategy for helping decision-makers evolve with grace; pushing will not yield the desired result.

WSJF, the prioritization tool introduced by Reinertsen and applied by SAFe aims to make this difficult task easier. We consider WSJF in four micro-conversations:

Perceived user-business value
Time criticality
Risk reduction and/or opportunity enablement value
Job size

The conversation is facilitated by reviewing each of these elements in isolation from the others. For example, if we have a list of ten jobs, we’ll first determine the user-business value score for each using a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20) and scoring guardrails. The guardrails should represent work that has been done previously to ensure consistent estimation. In my experience, I’ve found it helpful to have points of triangulation identified for each element of WSJF that represent a 2, 8, and 20.

WSJF is calculated by first determining the cost of delay through the summation of the user-business, time criticality, risk reduction and/or opportunity values, and then divided by job size. Based on the definition of the feature at the time, architects and other people who are responsible for delivering the work, will determine the job size independently of the other values.

Considering Reinertsen’s guidance, we agree that the jobs with the highest WSJF value represent the highest-value jobs that can be done in the shortest time possible.

It’s also worth noting that the WSJF prioritization isn’t final. We need to keep other factors top of mind, such as dependencies and availability of skills. And we need to make sure we always consider the economics and greatest benefit to the system.

Just-enough thinking helps us move faster

Consider the 10th principle behind the Agile Manifesto: the art of maximizing the amount of work not done is essential. We know that given the 80/20 rule, 80 percent of the value of a product comes from 20 percent of its features. The rest are rarely if ever, used.

Consider your bank’s website. I suspect that when you log into your account, you focus on three primary functions: reviewing your checking account, reviewing your savings account, and transferring money between the two. Not that loan applications, external transfers, and mobile deposits aren’t important. But to get the most value in the shortest amount of time possible, you likely focus on surfacing checking, savings, and transfer first. Additional functionality would come in a subsequent release. Waiting until all of the functionality was complete before launching the online banking platform likely seems foolish in the context.

WSJF forces us to focus on the features or ideas that are going to drive the most value at a given point in time. What are the checking, savings, and transfer functions relevant to you? Are you choosing to look at the work as a bank website, which is really big and would fail the prioritization conversation every time? Or have you broken the work up into smaller, high-value chunks? If you want your work to get prioritized, make sure that it’s small and highly valuable in the eyes of the customer. Small jobs move through the system (and delight customers) faster.

It requires leadership

Shifting our approach to prioritizing work is hard, but so is meaningful change. Winning in the post-digital economy depends on an organization’s ability to rapidly shift to meet changing market conditions and customer demands. Leaders who position themselves and their teams to be resilient in the face of change will win the digital future. Those who delay or don’t change will struggle to remain relevant.

What’s probably hardest of all is that for those in a leadership role, it’s highly unlikely that anyone will give them permission to behave in this way. In fact, doing so may come at great risk. Being a change agent is a difficult and thankless role, but one that organizations need now more than ever. If you’re a leader reading this post, it’s likely that your organization is already on the path to changing its work habits. It’s now up to you, the leaders, to determine how successful the change, and your organization’s future, will be.

About Adam Mattis

View all posts by Adam Mattis

Back to: All Blog Posts

Explore more Blog Posts

Next: Planning to 100% Capacity? Don’t Do It!

Read the Blog Post

Agile Planning to 100% Capacity? Don’t Do It!

Posted on June 14, 2021

Someone asked me the other day why Agile teams don’t plan to full capacity. Think about this scenario: during the last PI, a team on the ART achieved 50 percent of its planned business value. Stakeholders weren’t pleased with that result. When the team held its retrospective to examine its performance, several issues came to light. High turnover and lots of team members shifting between teams prevented them from finding their groove. People were experiencing burnout from moving too quickly while trying to correct quality issues.

As a scrum master, I coach my teams to plan to less than 100-percent capacity (see scenario above). But I understand why that doesn’t always make sense to stakeholders. They worry that it will result in even fewer met commitments. Teams need a way to talk to stakeholders about how they need to plan less and yet somehow deliver more. It’s easy to criticize the stakeholders. Of course they’re going to ask for more—that’s their job! They may not understand why agile teams estimate and how they plan agility. They don’t see the burden that agile planning to maximum capacity places on the team.

We need to shift the stakeholders’ perspective. So, here are five key things I’ve learned about capacity and predictability that could be persuasive input.

1. Agree on what capacity means

In a recent iteration planning meeting, I asked the team to give me a number that represents our capacity. There was general consensus that we should plan to 80 percent capacity. It didn’t take long to realize that we all had different ideas about what it means to allocate 80 percent of our capacity. Is it 8 points per person? Or 80 percent of 8 points? Doesn’t SAFe^® tell us somewhere?

SAFe doesn’t prescribe a measure. Whether we agree that our team’s capacity is 45 story points or 200 hours, what matters is that the team agrees to some quantitative measure of their capacity for progress.

2. Balance business needs with team capacity

A little pushing outside our comfort zone is a good thing, and can even be inspirational. Often, it’s uncomfortable to try new things, such as setting goals to do more or work faster than we have before. Yet that discomfort can lead to growth and achievement. Think about athletes getting better by pushing themselves to do things they’ve never done before—run faster, lift heavier, jump higher. As a team, we want to win the championship!

But when we push too much, we experience burnout, high turnover, and a lack of creative problem solving because we’re constantly rushing to meet deadlines. Take the athlete analogy—rest, recovery, and refueling via sleep and nutritious meals are essential to an athlete’s success. Otherwise, they risk injury, burnout, and decreased athletic output. Simply put, we need to help the team find its balance so it can thrive.

3. Find confidence in your understanding of the work

Whether your team is developing software, creating marketing strategies, or negotiating a contract, the amount of time required to complete any given task will vary. New teams and ARTs might take more time as they’re forming and storming. Building a new product could take more time during the early development stages because we don’t know how it will be received by customers.

When estimating the size of work, my team uses several perspectives. We assess work based on three criteria: volume, complexity, and our knowledge about the work. We ask ourselves questions like: Have we done this before? How much space do we reserve for the unknowns? Through conversations, we all gain a better understanding of the work. Our certainty in estimating fuels our confidence that we’re pushing ourselves to achieve excellence without the risk of burnout.

4. Protect space for built-in quality and problem solving

I like to keep a monthly budget for personal finance. I know from experience how unwise it is to spend all the cash I earn! I need to be able to respond to life’s unknowns, so I reserve some income for savings. It’s also smart to invest in the future. Early in my career, it was hard to imagine allocating any of my hard-earned salary for investing. (“I’ll start next year!” I’d tell myself.) But every day that went by was a missed opportunity.

The same concepts apply to teams approaching problem solving and innovation. We need “savings” to respond to life’s inevitable unknowns. Innovation can be applied incrementally, like little investments. When the team is constantly rushing to meet an overwhelming list of iteration goals, it’s like living paycheck to paycheck.

5. Slow down to speed up

As a sailor in the U.S. Navy, I learned the saying, “slow is smooth and smooth is fast.” When we were performing meticulous, potentially dangerous tasks aboard naval ships, time was of the essence, and safety and accuracy were paramount. Go too fast and you risk sloppy performance, decreased accuracy, and an unsafe environment. Conversely, go too slow and you risk the mission. As sailors, we lived by “slow is smooth and smooth is fast” to develop awareness and learn to strike the balance between speed and accuracy.

Agile teams are similar. They need time and space to define and automate their processes and to create the environments and infrastructure to ensure built-in quality. Slowing down this PI helps accelerate the next, and with higher predictability.

As I was writing this post, I spotted a conversation about capacity happening in the SAFe Agilists forum on the SAFe Community Platform (login required). Forums like these are great places to ask questions, share your knowledge, and learn something new. I hope you’ll check them out the next time you’re looking for advice.

About Sam Ervin

Sam is a certified SAFe® 5.0 Program Consultant (SPC) and serves as the scrum master for several teams at Scaled Agile. His recent career highlights include entertaining the crowd as the co-host of the 2019 and 2020 Global SAFe® Summits. A native of Columbia, South Carolina, Sam lives in Denver, CO, where he enjoys CrossFit and Olympic weightlifting.

View all posts by Sam Ervin

Back to: All Blog Posts

Explore more Blog Posts

Next: The Power of Customer Feedback in Prioritizing Work

Read the Blog Post

VoC: The Power of Customer Feedback in Prioritizing Work – Agility Planning

Posted on June 14, 2021

Welcome to the third post in our value stream identification in practice blog series. You can read the first post here about preparing for a successful workshop. And the second post here with helpful tips for identifying value streams.

The Scaled Agile Voice of the Customer (VoC) is a community of our most inspiring customers. All of whom are driving measurable change at their organizations.

This group of individuals comes together—virtually and twice a year—to share, connect with each other, and give us feedback to help us prioritize our most important work. Pretty simple, right? But very powerful in practice.

That power resides in how the VoC has been designed to promote continuous exploration and customer centricity. Each time we meet, we do exercises that encourage our community to look both backward (this is what we built based on your previous feedback) and forward (defining what our epic priorities should be). For example, at our last VoC event, Dean Leffingwell spent some time reviewing what we had worked on over the past six months.

We also went through an exercise called “Prune the Product Tree,” which is designed to reveal the features most important to our customers. Participants place apples, which represent features, onto a tree. Items nearest the trunk are a higher priority than those placed farther up the tree.

From our customers, we heard quite clearly that organizing around value was the top-rated epic. The overwhelming agreement within the community around this feature kicked off a renewed internal focus on Principle #10: organizing around value. Although we now had our purpose, we weren’t sure how to get started, nor what part of organizing or mapping value was the biggest challenge. So before jumping in and creating new tools and materials, we went back to our community to gain more clarity about the needs.

a chart depicting an exercise known as "Prune the Product Tree"

We asked some of our participants to spend 30 minutes with us in an empathy interview. We wrote a script of eight, open-ended questions designed to help us understand how organizing around value applies to their context. The questions were intended to uncover the obstacles they faced in organizing around value. Some of the biggest challenges were related to preparing for the workshop and getting executive buy-in to attend. One aha moment was when we learned how many organizations stand up ARTs without relying on the Value Stream Identification Workshop. So, our new guidance would actually need to reflect that reality.

Now that we had a sense of next steps, we knew it was important to bring our customers along for the journey to keep us moving in the right direction. We created a study group representing a smaller subset of our VoC community. As the name implies, this group’s purpose is to gather and apply a critical eye to new intellectual property and how it serves the challenges they identify.

This VoC study group has been critical in helping us understand the complexities large organizations face as they organize around value. But we’re not finished yet! With this group’s help, we’re developing new pre-workshop guidance. Our goal is to create new tools that will better serve our internal champions by:

Generating buy-in: getting executive level and internal support for holding the workshop. The 10 Tips for Value Stream Identification blog post is a good place to start.
Preparing for the workshop: tasks that should be completed to ensure a more successful workshop. Read more in the Three Steps to Prepare for a Successful Value Stream Workshop blog post.
Facilitating the workshop: guidance for creating an interactive and action-oriented event.
Taking action: tips for implementing workshop results.

In fact, we’re testing it out this quarter with the study group. And, as always, keeping the customer at the center as we design, test, and iterate.

Want to see the impact of the group’s feedback on early guidance? Some of the updates include:

Value Stream and ART Identification Workshop toolkit. Or, navigate to the “Implement” tab on the SAFe Community Platform, selecting “SAFe Toolkits & Templates,” then selecting “SAFe Value Stream and ART Identification Workshop Toolkit 5.1.”
What’s new in SAFe 5? How about Operational Value Streams as first-class citizens?

About Jennifer Roberts

Jennifer Roberts leads the Voice of the Customer community within the Marketing Enterprise Solutions team. Prior to joining Scaled Agile, she worked at Cisco where she led the global social selling and demand generation team. She lives in Boulder, Colorado and does not believe chili has beans.

View all posts by Jennifer Roberts

Back to: All Blog Posts

Explore more Blog Posts

Next: 10 Tips for Value Stream Identification

Read the Blog Post

10 Tips for Value Stream Identification – SAFe Implementation

Posted on June 14, 2021

Welcome to the second post in our blog series about value stream identification in practice. Read the first post here about preparing for a successful Value Stream and ART Identification workshop.

When deciding where to launch an Agile Release Train (ART), it can be tempting to look within existing organizational boundaries. But, considering Lean-Agile Principle #10, which reminds us to organize around value, we must challenge ourselves to look outside of our comfort zone, and consider a team more optimally focused on delivering value.

In light of organizational politics, doing so can be challenging, if not scary. To help people focus on the task at hand, we’ve developed a Value Stream Identification workshop. It can be especially helpful for organizations that aren’t actively managing value streams. It also teaches all those who attend the Implementing SAFe® course the method to facilitate a value stream identification event.

All SPCs are trained to facilitate a value stream mapping activity. But executing these workshops is an art mastered only after you’ve done in-depth studies on the topic (check out Value Stream Mapping by Karen Martin and the SAFe Value Streams article to start), and have participated in several events under the guidance of a skilled practitioner.

If you’re a new SPC who doesn’t have the opportunity to co-facilitate an event, here are 10 tips to help make your first few value stream identification sessions more productive.

Your operational value stream is probably bigger than you think.

When considering your operational value stream, remember the baseline definition of a value stream:

“… set of actions that take place to add value to a customer from the initial request through the realization of value by the customer. The value stream begins with the initial concept, moves through various stages of development and on through delivery and support. A value stream always begins and ends with a customer.”

Or, simply stated, from concept to cash.

In my years of helping organizations better understand their value streams, I’m often presented with initial maps that begin with input from an upstream process and end with an output to a downstream process. These aren’t value streams. To understand the value stream that your ART serves, it’s likely you need to zoom out from the perspective you’re most familiar with and consider the products and services that you support. I often direct people seeking to understand their value streams to start with the products or services section of their organization’s website. Another point of reference is the organization’s earnings report. A profit and loss statement will often represent the organization’s operational value streams.

Your development value stream probably doesn’t follow organizational structures.

The development value stream, which is where your ART(s) will align, represents the design-build-test activities that support change within the operational value stream. Though it may be tempting to align development value streams and ARTs to the organization’s reporting structures, this is suboptimal. To determine the best development value stream alignment, you must first understand the complexity of the social network required to serve the operational value stream. How? By gaining clarity around architectural complexity, or understanding who must collaborate and how often to develop valuable changes to the operational value stream. Over time, our goal is to simplify and optimize both technical and business architectures. To start doing that, we must do our best to optimize for flow by reducing bottlenecks associated with handoffs and dependencies.

After identifying the operational value stream, we continue the conversation of value stream identification. This is where we seek to understand the systems that support the operational value stream, and which steps of it they interact with. The resulting picture will help us make a more informed decision of where to align our development value stream, and determine which type(s) of development value stream supports our operational value stream.

Agreeing with operational and development value stream alignment is harder than you think.

Aligning around value, though critical to delivering better products and services to customers faster, is often challenging. In large enterprises that historically reward those who operate well within the hierarchy, the goal to operate well cross-functionally may feel difficult. The leaders of each functional area are asked to relinquish control of their organizations to better serve the customer. Though few will argue the merit of such a decision, we must be empathetic to the fact that this sort of change is difficult and often scary.

As a value stream identification workshop facilitator, you’ll find it valuable to proactively partner with the organization’s change management professionals to better understand the audience impacted by the workshop. These change professionals can help you better understand potential roadblocks and relationships. And they can recommend conversations you should have before the workshop to begin establishing trust, rapport, and purpose.

You may have more guidance than you think.

Understand the nuance between value stream identification and value stream mapping. Value stream mapping is the art and science of defining, measuring, and optimizing value streams and capabilities over a long period of time. SAFe discusses value stream identification in the context of launching an ART. It’s where we need to have an informed discussion of the most logical place to launch an ART based on our best understanding of how value flows within our area of influence. Value stream identification doesn’t replace value stream mapping but certainly proves the need to invest in the latter.

Words matter. When referencing the one- to two-day workshop to determine the best place to launch an ART, be careful to reference this as value stream identification. A business architect’s job is to maintain and optimize value streams and their underlying capabilities. If they overhear a well-intended SPC state that they intend to map a value stream in a day or two, the SPC may inadvertently make an adversary out of a would-be supporter.

If the organization you’re working with happens to have business architects on staff, then there may be many more inputs available for the value stream identification conversation than you’d initially suspect. If so, seek to partner with the business architect and leverage the assets they’ve created. At the very least, the fact that these people exist indicates an undeniable organizational willingness to organize around value.

Your business architecture will make it hard.

The architecture of a business, the flow of processes and interactions from concept to cash, will introduce complexity to the value stream identification exercise. Those complexities will typically represent years of acquisitions (without integration), good and bad relationships, canceled projects, partially finished projects, and other forms of organizational debt.

One of the most exciting—and troubling—things about an Agile transformation is how the new ways of working effectively shine a spotlight on issues that have been plaguing the organization for years. This is your opportunity to do something about it. Remember, the goal of value stream identification is to make an informed decision about the best, most logical place to launch your release trains. And those ARTs will evolve as the organization and architecture change. The goal isn’t to solve all of the organization’s challenges. But be aware of what you learn so that you can address the challenges and complexities moving forward.

Your technical architecture will make it harder.

As messy as an organization’s business architecture may be, it’s likely that its technical architecture is worse. I’m talking about outdated systems, mainframe databases, hard-coded variables, and systems that we’re not too sure of what they do, but certain that it’s something important. The conceptual diagrams of most architectures tend to look like a hurricane.

Though challenging, this is also a huge opportunity. If the intent is to move faster and with greater stability, you must invest in reducing technical debt, refactoring, and modularizing their architecture. The value stream workshop can help identify some of the largest risks in the technical architecture and begin aligning people in a way that will support a better future state.

A good way to think of investments in business and technical architecture is to reflect on this video.

The goal of a race is to cross the finish line first. Pitstops are an obvious bottleneck in that process. To alleviate delays in the pit, engineers and team owners had to invest in developing specialized skills among the pit crew and specialized tools optimized for efficiency. And redesign the car with the intent of making every component on it as fast as possible. This includes the architecture for changing tires, fueling, and more. These days, nobody is polishing the windshield. Instead, the visor on the driver’s helmet has been optimized to minimize glare, shed water, resist fog, and with roll-offs for when things get messy.

What’s your organization’s race car? What investments do you need to make in the car so that your organization can achieve its goals? Investments in architecture aren’t optional. But you should make it clear how each investment will help the organization perform at a higher level.

There are several types of operational value streams.

When considering operational value streams in an organization, it’s important to be aware that there are more than one type.

Fulfillment value streams represent the steps necessary to process a customer request, deliver a digitally enabled product or service, and receive remuneration. Examples include providing a consumer with an insurance product or fulfilling an e-commerce sales order.

Manufacturing value streams convert raw materials into the products customers purchase. Examples include consumer products, medical devices, and complex cyber-physical systems.

Software product value streams offer and support software products. Examples include ERP systems, SaaS, and desktop and mobile applications.

Supporting value streams include end-to-end workflows for various supporting activities. Examples include the life cycle for employee hiring and retention, supplier contracting, executing the annual budget process, and completing a full enterprise sales cycle.

Development value streams support operational value streams.

While operational value streams may vary significantly depending on their purpose, the development value stream steps are fairly standard: design, build, validate, and release the systems that support the operational value stream as it delivers value to the end-user. The titles of the people who work within the development value stream will vary based on the specific type of work being done, but the responsibilities of the people involved with the development value stream will be aligned with the steps mentioned above.

This is only a starting point.

Remember, the value stream identification workshop is designed to help people determine the best, most logical place to launch a release train. The decisions made in the workshop are a starting point. Following the workshop, reflect on opportunities to improve business operations, technical architecture, and the benefit of actively managing value streams for flow. Launching your first ART, development value stream, and portfolio is only the beginning of a lifelong pursuit to improve.

Once you start, evolve and seek excellence.

As you continue to optimize your operations and architecture, expect that the ART configuration and team topology will evolve. As the Agile Manifesto reminds us, we hope to build resiliency through a commitment to responding to change by following a plan. And the SAFe House of Lean reminds us how important it is to commit to relentless improvement in pursuing value delivery.

Look for the next post in our blog series about how our voice of the customer sessions influenced Scaled Agile’s recent value stream work.

In the meantime, you can download the updated Value Stream and ART Identification Workshop toolkit by navigating to the “Implement” tab on the SAFe Community Platform, selecting “SAFe Toolkits & Templates,” then selecting “SAFe Value Stream and ART Identification Workshop Toolkit 5.1.”

About Adam Mattis

View all posts by Adam Mattis

Back to: All Blog Posts

Explore more Blog Posts

Next: Three Steps to Prepare for a Successful Value Stream Workshop

Read the Blog Post

Launching an ART? Do a Gemba Walk – Implementing SAFe

Posted on June 14, 2021

What if you could see a great example of SAFe^® in the wild; a vision of a possible future as you prepare to launch your first ART? Would you want to stand in the middle of where the work is done and gain insights into what could inhibit your success? I’d like to share an approach I’ve used to leverage the power of a Gemba walk. I believe it to be one of the most powerful accelerators available for those considering implementing SAFe.

What is Gemba?

Gemba is a Japanese term that means “the real place.” It represents going to where the work is done or the place where value is created from a Lean-Agile perspective. Within an automotive plant, it’s the manufacturing floor, at a hospital, it could be the ER or operating room, and in the U.S. Government, it could be inside a Sensitive Compartmented Information Facility (SCIF).

Traditionally, a leader would take a Gemba walk to visit where the work is being done to observe the value being created and interact with the people and processes. Together, they can identify opportunities for improvement. Within SAFe, Gemba walks are among the collaborative research techniques product management will use for continuous exploration.

I encourage enterprise executives, Lean Portfolio Management executives, and ART stakeholders to take Gemba walks of PI Planning from a relentless improvement perspective. Gemba walks to allow them to truly understand the Framework while raising awareness of systemic issues that may require senior leadership assistance. Even before you’ve launched your ART, a Gemba walk of PI Planning is valuable. It is similar to someone looking to invest in a restaurant franchise who visits an existing location to get a closer look at what might be ahead of them.

While I have used this within large corporations, I have found it particularly applicable to the federal government. Many of the corporation-to-corporation or even business-unit-to-business-unit challenges that exist in the private sector do not apply as civil servant leaders are, ultimately, all part of the same overall entity. I’ve seen an incredible willingness for government leaders to share with others across agencies, such as the USAF/US Army program leader inviting NASA leaders to observe PI Planning before their ART launch. In this case, “the real place” is a live PI Planning event for an established ART.

Doing a Gemba Walk at PI Planning

As you can imagine, observing PI Planning before attempting to launch your ART will always provide valuable insights. Even if you only glean some examples of things you might do differently, there is no substitute for actually experiencing a live event.

I recommend you find the best example of SAFe you can and arrange to observe it with an experienced tour guide.

Tip: Look for ARTs organized around value, with dedicated Agile teams that meet the commitments they make themselves. If you can, find an ART where the Business Owners, Product Management, System Architect, and RTE have cleared their schedules to be 100-percent available during the entire event. Seek an ART where leaders demonstrate Lean, Agile, and SAFe values in how they work while genuinely seeking to cultivate transparency, create alignment, and deliver value together.

Interested? Here are the steps I like to take:

1. Find an ART that represents the type of SAFe implementation you hope to achieve yourself. Starting with the practices alone can still bring value, as not every company, business unit, or government program is ready to weave the values and principles necessary for great success. Additionally, some see SAFe as a process to be implemented by the numbers, pushing practices out, and directing how everything will work. Others understand that implementing SAFe, or any scaling agile framework requires shifts in mindsets and people making decisions based on new values and principles. I focus on the latter, as it’s the one that creates the deep roots needed to sustain and grow.

2. Obtain permission from the program leaders, understand what values they seek from experience, and address any concerns. Often, this idea of a Gemba walk is part of the introduction email between leaders of both programs.

3. Facilitate an orientation meeting before the planning event. This orientation allows you to introduce leaders from both programs, review the host ART’s schedule, and set the working agreements to ensure minimal disruption and maximum learning. Additionally, this meeting allows the host to share any context-specific ways they have leveraged the Framework. The visitors and the tour guide will understand the reasons for the changes before observing the event.

Tip: If remote, provide an overview of the tooling and methods used to replicate the deep collaboration model present in a face-to-face event.

4. Arrange for a dedicated tour guide who doesn’t need to facilitate the actual PI Planning event. If they have an SPC, as well as experience coaching ART launches, I recommend that the new program’s coach be the guide. Otherwise, the existing coach from the host program is a solid choice. The purpose of the tour guide is to help the visitors connect their knowledge to the field experience while highlighting best practices and answering questions in real-time without disrupting the host ART’s event. Ensure that everyone stays connected by having a persistent chat channel available for coaches and visitors throughout the event, and pre and post syncs to reflect on the insights gained.

Tip: If you consider bringing in an SPC as a coach or consultant, deeply explore their field experience. You might even find one who has a previous customer willing to share their perspective or allow you to observe their PI Planning event.

5. Allow visitors to observe the entire PI Planning event. If this isn’t feasible, see how many of the key events are available, such as opening briefings, team breakouts, plan reviews, management review, ROAMing of program risks, and the confidence vote. Understanding the host’s parameters and the visitor’s role can help you prioritize if time is limited.

6. Facilitate daily meet-afters between both sets of leaders. Standing meet-afters provide a safe forum to ask tough questions and discuss sensitive topics with honesty. Those who have the experience can share their tips and tricks with those preparing to embark on their SAFe journey.

7. Encourage connections between each visitor and the individual in their corresponding ART role. Personal relationships create an opportunity for those in the various roles to connect beyond the event. These introductions also can spark the creation of role-specific communities of practice.

Remember: SAFe is a framework, and while some essential elements, patterns, and practices lead to success, it is not one size fits all. As you look to customize your implementation, understanding why the methods are in place and which values and principles power them will serve you well.

A Gemba walk is one of the best ways to turn your knowledge of PI Planning into real understanding. It provides insights for hosts and visitors alike while creating community connections that foster alignment, transparency, quality, and execution.

Gemba resources

If you would like to learn more about Gemba within the Framework, check out the Continuous Exploration article. If you want to take a deeper dive, Jim Womack’s book, Gemba Walks Expanded, 2nd Edition is a great resource, and you can connect with one of the SAFe Fellows through the “Ask an Expert” forum on the SAFe Community Platform portal (login required).

About Phil Gardiner

Phil Gardiner, a SPCT, is focused on enabling people to achieve sustainable success through greater business agility. He has served various markets from Fortune 10 corporations to the U.S. federal government.

View all posts by Phil Gardiner

Back to: All Blog Posts

Explore more Blog Posts

Next: Uncovering Your Organization’s Hidden Learning Networks

Read the Blog Post

Understanding Leading Indicators in Product Development and Innovation

Posted on June 14, 2021

It’s quite common for people to nod knowingly when you mention leading indicators, but in reality, few people understand them. I believe people struggle with leading indicators because they are counterintuitive, and because lagging indicators are so ingrained in our current ways of working. So, let’s explore leading indicators: what they are, why they’re important, how they’re different from what you use today, and how you can use them to improve your innovation and product development.

What Are Leading and Lagging Indicators?

Leading Indicators in Product Development

Leading indicators (or leading metrics) are a way of measuring things today with a level of confidence that we’re heading in the right direction and that our destination is still desirable. They are in-process measures that we think will correlate to successful outcomes later. In essence, they help us predict the future.

In contrast, lagging indicators measure past performance. They look backwards and measure what has already happened.

Take the example of customer experience (CX). This is a lagging indicator for your business because the customer has to have the experience before you can measure it. While it’s great to understand how your customers perceive your service, by the time you discover it sucks it might be too late to do anything about it.

ROI is another example of a lagging indicator: you have to invest in a project ahead of time but cannot calculate its returns until it’s completed. In days gone by you might have worked on a new product and spent many millions, only to discover the market didn’t want it and your ROI was poor.

Online retailers looking for leading indicators of CX might look instead at page load time, successful customer journeys, or the number of transactions that failed and ended up with customer service. I often tell clients that if these leading indicators are positive, we have reason to believe that CX, when measured, will also be positive.

Don Reinertsen shares a common example of leading vs. lagging indicators: the size of an airport security line is a leading indicator for the lagging indicator of the time it takes to pass through security screening. This makes sense because if there is a large line ahead of you, the time it will take to get through security and out the other side will be longer. We can only measure the total cycle time once we’ve experienced it.

If you operate in a SAFe^® context, the success of a new train PI planning (which is a lagging indicator) is predicated on leading indicators like identifying key roles, training people, getting leadership buy-in, refining your backlog, socializing it with the teams, etc.

Simple Examples of Successful Leading Indicators

The Tesla presales process is a perfect example of how to develop leading indicators for ROI. Tesla takes refundable deposits, or pre-orders, months if not years before delivering the car to their customers. Well before the cars have gone to production, the company has a demonstrated indicator of demand for its vehicles.

Back in the 90s, Zappos was experimenting with selling shoes online in the burgeoning world of e-commerce. They used a model of making a loss on every shoe sold (by not holding stock and buying retail) as a leading indicator that an online shoe selling business would be successful before investing in the necessary infrastructure you might expect to operate in this industry.

If you are truly innovating (versus using innovation as an excuse for justifying product development antipatterns, like ignoring the customer) then the use of leading indicators can be a key contributor to your innovation accounting processes. In his best-selling book, The Lean Startup, Eric Ries explains this concept. If you can demonstrate that your idea is moving forward by using validated learning to prove problems exist, then customers will show interest before you even have a product to sell. Likewise, as Dantar P. Oosterwal demonstrated in his book, The Lean Machine, a pattern of purchase orders can be a leading indicator of product development and market success.

Leading Indicators Can Be Near-term Lagging Indicators

Let’s loop back and consider the definitions of leading and lagging indicators.

Lagging: Measures output of an activity. Likely to be easy to measure, as you’ve potentially already got measurement in place.
Leading: Measures inputs to the activity. Often harder to measure as you likely do not do this today.

Think about the process of trying to lose weight. Weight loss is a lagging indicator, but calories consumed and exercise performed are leading indicators, or inputs to the desired outcome of losing weight.

While it’s true that both calories consumed and exercise performed are activities that cannot be measured until they’re completed, and therefore might be considered near-term lagging indicators, they become leading indicators because we’re using them on the path to long-term lagging indicators. Think back to the CX example: page load time, successful customer journeys, and failed transactions that end up with customer service can all be considered near-term lagging indicators. Yet we can use them as leading indicators on a pathway to a long-term lagging indicator, CX.

How to Ideate Your Leading Indicators

The most successful approach I’ve applied with clients over many years is based on some work by Mario Moreira, with whom I worked many moons ago. I’ve tweaked the language and application a little and recommend you create a Pathway of Leading to Lagging Indicators. To demonstrate this, I will return to the CX example.

If we walk the pathway, we can estimate that an acceptable page load time will lead to a successful user journey, which—if acceptable—will then lead to fewer failed transactions that revert to customer service, which ultimately will lead to a positive customer experience metric.

Work Backwards from Your Lagging Indicator

To create your Leading to Lagging Pathway, start from your lagging indicator and work backwards looking at key successful elements that need to be true to allow your lagging indicator to be successful.

At this stage, these are all presuppositions; as in, we believe these to be true. They stay this way until you’ve collected data and can validate your pathway. This is similar to how you need to validate personas when you first create them.

Add Feedback Loop Cycle Times

Once you have your pathway mapped out, walk the pathway forward from your first leading indicator and discuss how often you can and should record, analyze, and take action for that measure. You should make these feedback loops as short as possible because the longer the loop, the longer it will take you to learn.

All that’s left is to implement your Leading to Lagging Pathway. You may find a mix of measures, some which you measure today and some you don’t. For those you already do measure, you may not be measuring them often enough. You also need to put in place business processes to analyze and take action. Remember that if measures do not drive decisions, then your actions are a waste of resources.

Your leading indicator might be a simple MVP. Tools like QuickMVP can support the implementation of a Tesla-style landing page to take pre-orders from your customers.

Applying Leading Indicators in Agile Product Management

A common anti-pattern I see in many product management functions is a solution looking for a problem. These are the sorts of pet projects that consume huge amounts of R&D budget and barely move the needle on profitability. Using design thinking and Lean Startup techniques can help you to validate the underlying problem, determine the best solution, and identify whether it’s desired by your potential customers and is something you can deliver profitably.

In SAFe, leading indicators are an important element of your epic benefit hypothesis statement. Leading indicators can give you a preview of the likelihood that your epic hypothesis will be proven, and they can help deliver this insight much earlier than if you weren’t using them. Insight allows you to pivot at an earlier stage, saving considerable time and money. By diverting spending to where it will give a better return, you are living by SAFe principle number one, Take an economic view.

Let’s look at some working examples demonstrating the use of leading indicators.

Leading Indicators in Agile Product Management

I hope you can now see that leading indicators are very powerful and versatile, although not always obvious when you start using them. Start with your ideation by creating a Leading to Lagging Pathway, working back from your desired lagging indicator. If you get stuck, recall that near-term lagging indicators can be used as leading indicators on your pathway too. Finally, don’t feel you need to do this alone, pair or get a group of people together to walk through this process, the discussions will likely be valuable in creating alignment in addition to the output.

Let me know how you get on. Find me on the SAFe Community Platform and LinkedIn.

About Glenn Smith

Glenn Smith is SAFe Program Consultant Trainer (SPCT), SPC, and RTE working for Radtac as a consultant and trainer out of the UK. He is a techie at heart, now with a people and process focus supporting organizations globally to improve how they operate in a Lean-Agile way. You will find him regularly talking at conferences and writing about his experiences to share his knowledge.

View all posts by Glenn Smith

Back to: All Blog Posts

Explore more Blog Posts

Next: Traits of the Stoic Agilist

Read the Blog Post

Traits of the Stoic Agilist – Agility Planning and Scaling

Posted on June 14, 2021

Hollywood has a way of portraying philosophers as pretentious finders of fault. (Emily in Paris, I love you, but you are guilty of this.) What’s more, the mention of the stoic philosopher leads to images of people who are emotionless and incapable of feeling (Spock, anyone?).

These portrayals are unfortunate, because we all stand to learn a great deal from the stoics of ancient times. Especially agilists.

Over the last year, my wife and I have focused a portion of each day studying the stoic philosophers Chrysippus, Marcus Aurelius, Seneca the Younger, and Epictetus. Our daily meditation has helped us be in better control of our emotions and hone our world view. It’s helped me become a better consultant and coach. Most significantly, the lessons have helped my wife process what she has seen as a nurse in the year of COVID.

Each of us, agilist or otherwise, can build a healthier outlook by taking a moment to reflect on these ancient lessons. Here are a few insights I’ve gained that have helped me better engage with enterprises and agilists during this tumultuous year.

The discipline of perception

Clarity. For an agilist, clarity is achieved through a combination of education, experience, and making mistakes. The stoics remind us that we should remain humble as we gain more clarity. As we learn to observe, absorb, and reflect, we begin to recognize patterns, and we need to remain empathetic to the circumstances that cause these patterns. The more we learn, the more open we become to others’ circumstances, emotions, and conflicts.

Passions and emotions. As a coach or consultant, it’s incredibly important that we lead with passion, while keeping our emotions in check. The stoics remind us that the journey belongs to our client, and it is our responsibility to walk that journey with them. With a calm dignity, we must steady the impulse to act on what we think we know, to not give in to the self-fulfilling prophecy of fear that may be felt by those we are guiding, and to avoid making the job of change harder than it needs to be.

Awareness. The fall of many energetic agilists comes from an eagerness to act before fully appreciating the situation at hand. Awareness is where philosophy begins, and is the starting point of any transformative journey. We must observe, take the time to appreciate history, and seek to understand the interconnected nature of the people working within the system. We work with a firm footing in the present but with a keen eye on the future. One day, it will all make sense.

Unbiased thoughts. The Agile community is full of some of the most volatile, well-intended people I have ever come across. To their own undoing, many have firm opinions based on perception and bias. As the stoics teach us, the more we think we know about an issue, the less we understand. A person who remains unbiased, as all agilists should, will seek to understand, do their own research before forming an opinion, and welcome a change of perspective.

To be so firmly rooted in a position of being (Agile) or not leaves one in a position to be alienated and left behind by an ever-evolving idea.

The discipline of action

Right action. As we lead others along the pathway to a new way of working, it’s a common mistake to tell others what to do—especially when they ask you to. The problem with direction and execution is that context and intention, and thereby learning, are lost. As a SAFe coach or SAFe consultant, we must avoid this temptation and instead show a client what they need to do. You can accomplish this through demonstration, facilitation, and showing up to perform even on the hard days. In the spirit of carpe diem, we, along with our clients, must do our best to make the most of the present while maintaining awareness of the end goal, and giving little thought to the future.

Problem solving. In problem solving, we have to be flexible. As we learn through many problem-solving tools, the problem is rarely what we think it is. It’s in our best interest to remain flexible and to have a mental reverse clause, no matter how well we think we know what we know (the freedom to admit when you’re wrong.) There isn’t room for pride in problem solving; growth and learning is what we’re here for.

Duty. This is the single world embodying everything it means to be a servant leader. Servant leadership is a rallying flag common to nearly all agilists, but true servant leadership is a call few are willing to answer. The sense of duty that comes with putting the needs of others before your own is one of selfless service and sacrifice. As a servant leader, you must show up, do your job, learn, and embrace the ethos that doing the right thing for those you’re serving is the only thing you can do—even if it’s the wrong thing for you personally.

Pragmatism. One of the most important skills that pragmatism teaches those of us with an agile heart is to not expect perfection. Perfect agile is subjective and should never be the goal. Instead, focus on helping clients achieve better business outcomes, helping employees attain a healthier and more fulfilling work experience, and creating a culture that is focused on outcomes and free of blame.

The discipline of will

Fortitude and resilience. You’re going to fail. People will struggle. People will be angry with you. Do you have the fortitude to endure? Are you resilient enough to endure this again and again? Transformation is a messy job. It’s often thankless until the moment it isn’t, and then the agilist is on to the next engagement and asked to start over. It’s rare that the agilist is in a position to enjoy the fruits of their labor, but it shouldn’t be about that. We work with a steady resolve. We’re resistant to the blame, the negativity, and the haters. Our hidden power is to know what the pain is for. We know the indisputable benefits of our craft. We’ve seen lives transform and organizations flourish through this new way of working. All reasons why we shall endure, again and again.

Virtue and kindness. The most beautiful thing any of us can do is to be kind to others. Kindness is especially important when others are fraught with struggle and may not be able to be kind to you. Will you look out for those who are unkind anyway? The stoics teach us that character is fate. People won’t remember what you said, but they will remember how you made them feel, especially when they may be embarrassed by how they made you feel.

Acceptance. The strong accept responsibility. They never complain, they never explain. Instead, they seek to control their own attitudes and responses to those events. The only thing that could have happened will happen, and we must seek to learn all we can from that outcome. As a stoic agilist, we must do our best to apply the guidance of Marcus Aurelius (Meditations, 8.7), which suggests that our acceptance of events and nature moves freely when it:

Accepts nothing false or uncertain
Directs its impulses only to acts for the common good
Limits its desires and aversions only to what’s in its own power
Embraces everything nature assigns it

We accept the outcome of our best efforts, reflect, grow, and share.

Meditation. A career focused on changing human behavior and organizational psychology is not for the faint of heart. It takes strong resolve to let the little things go so that we can elevate ourselves from the day’s chaos to evaluate the big picture. Are we making progress? What is the goal? Where is their pain? Am I inflicting pain? How can I help make the situation better? Am I the person best suited to help this team?

As agilists, we must take the time to reflect, to ensure we’re not burning the candle at both ends, and to give thanks for the invitation to help others do what is hard. Our calling is noble, our purpose transcendent, and the impact undeniable. By studying the stoics we can help assure that we are showing up as our best selves and that we stay firmly rooted in the intent that brought us to this type of work.

If you are interested in developing a stoic mindset, check out The Daily Stoic by Ryan Holiday.

About Adam Mattis

View all posts by Adam Mattis

Back to: All Blog Posts

Explore more Blog Posts

Next: Taking the Sting Out of Remote Teaching with Scaled Agile’s Virtual Classroom

Read the Blog Post

Taking the Sting Out of Remote Teaching with Scaled Agile’s Virtual Classroom – SAFe Training

Posted on June 14, 2021

The backstory

Due to the global pandemic, almost overnight, we had to convert all 2020 SAFe® classes to virtual delivery. I’m most proud of how the worldwide SAFe community came together and experimented to figure out remote delivery. My contribution was to imagine the class experience and determine how to help instructors facilitate learning activities remotely. We came up with remote training aids which were simple slide templates for each activity that groups could collaborate indirectly. It was an early stage MVP in our journey to evolve remote learning.

Remote was not for the faint of heart

As instructors, we had to figure out the tooling and how to set up those templates for the class. I remember when I remotely delivered new Lean Portfolio Management Alpha and Beta classes, it took me close to 30 hours to set up the activities and groups for each class. Delivering back-to-back classes, while good for our work, was exhausting because setup activities would bleed into our evenings and weekends. I could definitely understand why some SPCs were hesitant to venture into remote delivery.

The virtual classroom evolution

We kept experimenting with different formats and tools in class, and learning with each one how to make the experience better. We started to use SAFe^® Collaborate, our cloud-based visual workspace, to standardize the activity templates. Early feedback was positive about the learning and ideation experience. But attendees still felt that having too many windows open was distracting and tedious, especially during activities with short timeboxes. For instructors, it took time to set up these templates for each group and class. And while we were able to automate a portion of the setup via script, that wasn’t the case for course updates. Instructors still had to revise class activities when Scaled Agile introduced a new class version.

During a hackathon at Scaled Agile, colleagues built an interactive virtual classroom prototype in SAFe Collaborate that solved the navigation and usability challenges.

This hackathon idea won first place and got approved as a feature during our next PI Planning.

Virtual classroom for the win

I recently taught my very first class using our virtual classroom, and it was such a wonderful experience. I’ve switched from being a sceptic to a fan because it’s so awesome! All the templates were indexed by lesson, well organized, and easily accessible for both students and teachers. Students could quickly navigate to their own group activity and even browse around to see what other groups were doing.

The learning experience was much richer and more fun for the students, especially when we got to the PI Planning simulation. The best part for me as an instructor? I could set up the class and groups with a single action! I simply showed up to class, clicked a button to designate the number of groups, and started teaching.

Lean Agile Centers of Excellence (LACEs) and SPCs that need to update templates with every course upgrade will score an even bigger win with the virtual classroom experience. Scaled Agile now provides the activity templates and automatically updates them when new course versions are released. This is a huge value and time saver.

If you’re an SPC or a LACE member, I encourage you to try our virtual classroom in your next class. Just select “SAFe Virtual Classroom” as you set up your next remote class, and explore the different activities. Or, watch the remote trainer enablement video to see a demo.

If you’re like me, you’ll find it hard to go back!

About Deema Dajani

Deema Dajani is a Certified SAFe® Program Consultant Trainer (SPCT).
Drawing on her successful startup background and an MBA from Kellogg Northwestern University, Deema helps large enterprises thrive through successful Agile transformations. Deema is passionate about organizing Agile communities for good, and helped co-found the Women in Agile nonprofit. She’s also a frequent speaker at Agile conferences and most recently contributed to a book on business agility.

View all posts by Deema Dajani

Back to: All Blog Posts

Explore more Blog Posts

Next: Three Ways Informal Learning Networks Emerge

Read the Blog Post

Using Agile Marketing How We Turned Business as Usual into Value Delivery

Posted on June 11, 2021

a group of business people in front of an agile marketing board

There are few sentences more toxic to a workplace than, “That’s the way we’ve always done it.” A marketing team is often tasked with ongoing maintenance work that must be done. Updating a webpage, a piece of collateral, or a social feed can often feel like everyday, run-of-the-mill work that rarely gets seen or appreciated. It just sort of runs in the background and quietly eats away at the work day. As a result, this unappreciated, untracked work usually gets thrown into an ever-expanding pile of just-get-it-done tasks that mandate no thought and no context. Before you know it, someone’s asking why we do it at all, and that toxic answer resurfaces: “That’s the way we’ve always done it.”

To me, this answer is a symptom of the larger problem. Born out of years of repetitive tasks that never see the organizational light of day. We always do it that way because we’ve never had the time to closely examine our process. Or, it’s been so long that literally no one can remember why those decisions were made in the first place.

Agile marketing provides multiple tools to marketing leaders to help focus their teams’ efforts. Our goal is to never just eliminate business as usual (BAU) work; just make sure it’s the right one. This was the challenge I faced when I recently took over an agile marketing team. How could I leverage the Scaled Agile Framework® (SAFe®) to make sure we’re doing the right work to keep the ART on track, rather than just busywork? Luckily, agile marketing gave me a few tools I never had before in previous marketing leadership roles. I have visibility into and clarity around the work that had never existed before, and my team has reaped the benefits.

Data: It’s not just for open rates anymore

Agile preaches that all work should be visible. But as previously stated, BAU work rarely is. Being an agile team that leverages a Kanban board to visualize the flow of work getting done, we made a small tweak. We tagged every user story that fit the description of BAU. Voilà! I could now pull clean reports on exactly what type of BAU we were working on, what percent of our time we were dedicating to it, and who on the team it affected the most.

We found that we were spending a staggering 31 percent of our time on BAU! And as we examined more closely, we found many people had no idea why we were working on these things at all. It was just the way we had always done it.

Most importantly, the ART and the team had no idea just how much time all this work was taking. No one had ever calculated it. By taking a data-driven approach to the issue of BAU, we did something crazy: We timeboxed it.

Capacity allocations

There are only so many hours in a day and any good leader wants to make sure their team is getting the top-priority things across the line. Our goal is not to eliminate BAU work, but to ensure it’s the right work. By following agile marketing practices we can calculate exactly how much we can accomplish in a two-week iteration. Leveraging ‘capacity allocation’ helps marketing leaders limit BAU’s ability to derail the priorities.

And that’s exactly what we did. Our team allocates 20 percent of our available time to deal with BAU work like website maintenance, monthly newsletters, and updates to graphics. This creates a forcing function in evaluating BAU. Is this BAU user story more important than another one? To answer that question, team members have to fully understand the work and the product owner (PO) has to understand the customer’s needs. If no one understands why they’re working on something, they shouldn’t be working on it.

To marketing professionals lookin at campaign performance charts for their latest campaign

Hypothesis-driven development

Marketers love a good A/B test. It’s short and simple. But harder, more in-depth questions like “Does this webpage provide value to the reader?” take more effort and thought. When evaluating BAU, we found we needed to develop some muscle memory around answering these harder questions. And we wanted something more defensible than our personal opinions.

To do this, we’ve introduced an agile marketing concept called hypothesis-driven design. Essentially, it means you develop a testable hypothesis and the experiment to validate or falsify it. In other words, you leverage the scientific method to evaluate your work.

After the team took the Agile Marketing with SAFe^®course, we began to apply hypothesis-driven design to our website and our underperforming monthly newsletters. This won’t come as much of a surprise to marketing professionals, but we found we’re pretty good at designing tests; not so great at writing hypotheses that can be tested. Introducing hypothesis-driven design was a meaningful step toward building more intention into our BAU work.

So what happened?

Since adopting these practices, our team has seen a 42 percent decrease in capacity spent on BAU. This work is being turned into productive, value-delivering efforts that support the ART’s overall go-to-market strategy.

By leveraging agile marketing we’re no longer just busy: We’re busy delivering value.

About Hannah Bink

Hannah Bink heads the Marketing Success team at Scaled Agile. She has nearly 15 years of B2B marketing experience and studied business at Pennsylvania State University. Prior to Scaled Agile, Hannah spent the majority of her career in telecommunications and healthcare sectors, running global marketing divisions. She is also author of the “Musings of a Marketeer” blog, and lives in Denver, Colorado.

View all posts by Hannah Bink

Back to: All Blog Posts

Explore more Blog Posts

Next: What is SAFe? Eight Facts About the Scaled Agile Framework That You Should Know.

Read the Blog Post

Why we perform value stream identification

The role of business architecture

Value stream mapping

Capability mapping

Capability modeling

Where to start

About Adam Mattis

Share:

Siloed behavior and organizational politics

Win culture

Take an economic view

Apply systems thinking

WSJF

Just-enough thinking helps us move faster

It requires leadership

About Adam Mattis

Share:

1. Agree on what capacity means

2. Balance business needs with team capacity

3. Find confidence in your understanding of the work

4. Protect space for built-in quality and problem solving

5. Slow down to speed up

About Sam Ervin

Share:

About Jennifer Roberts

Share:

About Adam Mattis

Share:

What is Gemba?

Doing a Gemba Walk at PI Planning

Gemba resources

About Phil Gardiner

Share:

What Are Leading and Lagging Indicators?

Simple Examples of Successful Leading Indicators

Leading Indicators Can Be Near-term Lagging Indicators

How to Ideate Your Leading Indicators

Work Backwards from Your Lagging Indicator

Add Feedback Loop Cycle Times

Applying Leading Indicators in Agile Product Management

About Glenn Smith

Share:

The discipline of perception

The discipline of action

The discipline of will

About Adam Mattis

Share:

The backstory

Remote was not for the faint of heart

The virtual classroom evolution

Virtual classroom for the win

About Deema Dajani

Share:

Data: It’s not just for open rates anymore

Capacity allocations

Hypothesis-driven development

So what happened?

About Hannah Bink

Share: